Re: [cdi-devel] [PATCH] CDI.audio

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Thu, Nov 18, 2010 at 04:13:02PM +0100, Max Reitz wrote:
> Matthew Iselin wrote:
> > I would presume the driver should sanitise the input (and possibly
> > create a a set of "in-advance" streams for buffers bigger than those
> > that the hardware can handle, ready to be used once the current stream
> > completes).
> 
> Hm, I don't really understand what you want to say... Both the number of streams (or channels, as Kevin proposed) as well as the number of buffers and their size are predefined by hardware (or, to be more precise: may be predefined by hardware) and will thus be unchangable by the driver. Hence, neither may a stream complete nor will a CDI.audio driver be able to create a new one out of the blue with an arbitrary buffer size.

I think what Matt means is that nobody forces the driver to push all
buffers to the device immediately, so a driver could keep some
additional buffers in RAM that it sends as soon as there are some
free buffers.

There seems to be a misunderstanding about what streams actually are. So
what I understand is that streams are the input interfaces of the
hardware mixer (so their number is given by the hardware), and each of
them has its own ring (?) of buffers in typical hardware
implementations. Is my understanding correct so far?

> > it might be worth delving into the source
> > code of an audio-based application as well as the source for something
> > such as pulseaudio to determine how that kind of stuff works - whether
> > "stop" is passed all the way down to the driver or not or if the
> > userspace audio layer does it.
> 
> Well, today I had a look into the mplayer code. Obviously it caches up to 64 kB (which equal several 100 ms of sound). If it wants to stop the current playback, it calls a function which forces the output device (e.g. ALSA) to drop all the data it sent. But I have absolutely no clue how this might be implemented. Maybe one would have to store all the input data and if one of those sources drops its samples, the mixer would have to remix everything without that source and replace the existing data in the sound card's buffer with that. Anyway, I think that's the mixer's problem and it's not really related to the sound card interface.

I agree until here.

But you have the mixer which must send its data to the hardware in the
same way. And now we've just recreated the same problem one level below.
So now the mixer has sent some data in advance to the hardware and needs
to take that back and possibly replace it by something else. This is
what I'm talking about.

> Maybe we should add an offset to the transfer_data function so the mixer doesn't have to replace all of the buffer's content in that case.

Might work, yes.

> However, it might be a good idea if I just write a simple sample AC97 driver to show how this interface is used...

Go for it. ;-)

Kevin

PS: Any chance to tell your mailer to wrap lines properly?