[CONTACT]

[ABOUT]

[POLICY]

Today want to share my experiences

Found at: vernunftzentrum.de:70/ckeen/phlog/2019-05-05-On-building-an-audio-player.md

                                                           2019-05-05
___O_n__b_u_i_l_d_i_n_g__a_n__a_u_d_i_o__p_l_a_y_e_r_________________
Today I want to share my experiences in building an audio player for
a child that has not learned to read (yet). In the household we rip
CDs as a backup or borrow media from friends to listen to. Audio
So the idea has been to use a media playing device that blends well
nto a children's room, is easy to use without having to read. Does
not snitch on its user due to software out of our control and plays
back any audio file that's been fed to it.
As you may guess, a research for ready made players has made me come
back empty handed. So I have decided to build my own. Since I had a
But how should I design the interface? I have seen ideas of using
the player to make it select the media but that seems wasteful to me.
cards would probably get lost soon.
So I decided for a visual media selection mechanism by offering an
mage of the original CD cover, which means the device should feature
a display of some sort. Touch interfaces are right out as they don't
buttons as they provide a nice click and come in colors.
Volume should be capped off at a limit set by us, so the volume knob
s an actual knob stuck on a rotary encoder.
s just another sound card wrt the linux kernel, so no further action
from our side was required.
The device should be powered on and off by itself, so I added a pololu
the same button to do the turning on, and hooked it also to a GPIO on
the arduino to detect the power off. That in turn will shut down the
The display is a 3,4" HDMI display by waveshare which came in a
The housing has been designed in OpenSCAD and I consider it to be in
beta stage. The holes for the speakers are a bit off and the through
The player software itself has been a breeze to write. It's a
The best design decision has been to separate the event generation
from the actual event handling, so whether the player is designed by
keyboard or actual GPIO is a matter of switching a dispatch
Determining the state transitions of the player as well as the non
volatile config stathas been a bit trickier but all was done in a
couple of hours. Then the debugging happened for some more hours.
The most annoying part has been the GPIO handling of the buttons.
mechanism has fit in perfectly in generating the correct events for
the main event loop in my code.
BUT it seems there's a bug in the debounce parameter when using it
the buttons are properly debounced and show exactly the effect I
For the moment the device's wifi has been left turned on for
available under link below
Stay tuned, I will put up pictures of the finished device when I wake
up again.
___References_________________________________________________________


AD: