[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Chris Robinson wrote:
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
As I said, I decided to rewrite the polling code because it was giving
me the "write error" sometimes, and it suffered from race conditions...
Now the PCM device is oppened with 0, and no polling is done.
Reuploaded everything to http://www.riteh.hr/~mmimica/allegro-alsa.zip
The example app now can use streams now.
The al_audio_set_* functions don't take effect until driver is reopened.
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.
I don't think there is need for this. We're not running in a interrupt
handler any more. A thread can wait for snd_pcm_writei to finish. Async
callbacks can be ugly because thay are... async.
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.
I'll see what about it.
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.
OK.
--
Milan Mimica
http://sparklet.sf.net