|Re: [AD] new ALSA driver|
[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]
On Saturday 02 September 2006 03:47, Milan Mimica wrote: > Chris Robinson wrote: > > Don't forget, when _al_voice_update returns NULL, you should play > > silence. You currently just rest and return. > > I still don't see what's wrong with resting. Because when you rest, you're not feeding anything to the card, so it'll risk an overrun. And since you don't feed it silence, the behavior becomes improper. I've also done substantial work on the driver. Multiple hardware voices, cleaner mode verification/selection when opening the voice, a proper sample caching API, etc (attached). > I noticed that the API lacks volume control of any kind. Am I missing > something? Volume control and panning are MIA, yes. For software mixing, these will be handled in the sample matrix. Although I'm not quite sure how to handle it with hardware mixing. I'm hesitant to change the hardware voice's volume since I don't know if that will have a lasting effect on the main hardware volume (something I'd want to avoid). I'd also like to be able to allow users to supply custom matrices to allow for user-defined effects, but this would be dependant on hardware mixing APIs having something similar that can be accessed. ALSA, at the very least, has a ttable structure which is identical to how the sample matrix is set up, so I could just copy the sample matrix into that. Unfortuantely I have yet to find a way to manipulate this (the "docs" don't help, and it is otherwise available only when defining the device in a .asoundrc file). If I have to though, I'll stick with just panning and volume control, but I'd like to get more if possible. There's also a question of how the hardware voices should behave. Currently with ALSA, each voice is completely independant of each other. What I'd like to do is be able to define a "main" output (eg. 16-bit, 44100hz, 4 channels), have voices with potentially different settings (eg. 16-bit, 22050hz, 1 channel) and be able to pan it around the "main" output area. This is how the OpenAL driver currently works. The only way to do it currently with ALSA, would be to make the user load/convert the sample to 4 channels, and load it into a 4 channel voice, which would (needlessly?) quadruple the memory requirement, not to mention cause problems with cards that have fewer multi-channel voices. With ALSA, there's the ability to use a routing table (which defines a slave/main output device, and an aforementioned ttable matrix to route the written data into the output channels). But I have no idea how to do this from the program code. It would reall make my life a lot easier if I knew how. > A function to get available driver names would be nice. Allegro drivers or system drivers? The former is doable once a main driver list is implemented (need to figure out a way to make compiled-in drivers automatically add themselves to a list). > And there is a bug with streaming. It's like the last fragment gets > repeated twice. It happens both with alsa and openal driver so the > problem must be somewhere else. I'll look into it.
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|