Re: [AD] new ALSA driver

[Chris Robinson <chris.kcat@xxxxxxxxxx>]

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.

Attachment: audio_api.tar.bz2
Description: application/tbz