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

[Max Reitz <max@xxxxxxxxxx>]

On Thu, Nov 18, 2010 at 18:41, Kevin Wolf wrote::
> 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?

Yes, it is.

>>> 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.

That shouldn't be a big deal. Just use transfer_data with the buffer which
is currently in use.

>> 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. ;-)

I just completed it, though I don't know (of course) whether it works,
because CDI.audio support is rare so far. *g*
It does compile at least. ;-)

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

I think not, but I tried to wrap them manually.


Max