Re: [AD] new ALSA driver

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


About the driver, you may want to look into using snd_async_add_pcm_handler:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#g5a0c0da6d0d35a3ac9f6a97567ac3b63

You'll need to open the PCM device with 0 or SND_PCM_ASYNC instead of 
SND_PCM_NONBLOCK, and that (I believe) will allow ALSA to use a callback 
function every time a fragment is finished, which you could use to call 
_al_voice_update without having to use loop+poll threads (assuming the 
callback doesn't have the program's threads blocked from running somehow). 
You'd pass it the voice struct as the private data, then use 
snd_async_handler_get_callback_private to retrieve it in the callback.

For an example of use, check the two functions starting at line 365:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a98


Also, I foolishly assumed most drivers capable of hardware mixing would be 
able to store the sample data themselves (like OpenAL and DSound can). It 
appears this isn't the case though, so I think a future improvement will be 
to make a generic sample cache+retrieve API that multiple drivers can use.


You may also want to store multiple device names instead of just one (seperate 
device names for 1-channel, 2-channel, 4-channel, 6-channel, and 8-channel). 
Xine-lib does this for its configuration with ALSA, and makes it much easier 
when switching between, say, stereo output to 4 or 5.1 output. It may also be 
best to dissallow the enums for LFE modes in alsa_set_enum. The idea being 
that the actual device doesn't know or care what the channels are (6-channel 
could be 5.1 or 6), so you'd only allow values where val&0xF is 0. The user 
would then be responsible for setting the device names for the given channel 
count to get the right configuration.


Finally, instead of having an AL_AUDIO_ENUM_LAST, an AL_AUDIO_USER_START that 
is a sufficiently high value (0x10000?) would probably be a better idea so it 
won't conflict with potential future additions to the enum list.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/