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

[Kevin Wolf <kevin@xxxxxxxxxx>]

On Thu, Nov 18, 2010 at 08:00:34AM +1000, Matthew Iselin wrote:
> A few thoughts from me.
> 
> On Thu, Nov 18, 2010 at 7:45 AM, Kevin Wolf <kevin@xxxxxxxxxx> wrote:
> > On Wed, Nov 17, 2010 at 09:04:22PM +0100, max@xxxxxxxxxx wrote:
> >> From: Max Reitz <max@xxxxxxxxxx>
> >>
> 
> >> +    /**
> >> +     * \german
> >> +     * Ist dieser Wert ungleich 0, so handelt es sich um ein Aufnahmegerät,
> >> +     * es kann nur gelesen werden. Ist er 0, dann können nur Töne abgespielt
> >> +     * werden.
> >> +     * \endgerman
> >> +     * \english
> >> +     * If this value is not 0, this device is a recording device, thus one can
> >> +     * only read data. Otherwise, only play back is possible.
> >> +     * \endenglish
> >> +     */
> >> +    int record;
> >
> > Hm, shouldn't that be a property of a stream/channel? It seems odd to
> > have two devices appearing in the system for one physical sound card,
> > just to have one for playback and one for recording. It's like having
> > a different devices for reading from a disk than for writing to it.
> 
> What about a system with a sound card that offers three inputs and six
> outputs? To the OS all three inputs should appear as unique devices
> unless they are not separate on the sound card.
> 
> Something to consider.

I guess the decision we have to make here is whether this should appear
as nine independent devices to the OS, or as one device providing
multiple inputs and outputs.

As a user I think I would expect that some kind of device manager shows
the one sound card I have, not one input device and one output device
(sorry, I don't have as fancy hardware as you ;-)) which aren't separate
boards in my computer.

But then, there are probably good points for the opposition and in the
end it's a matter of taste. I won't insist on a change here.

> >> +
> >> +    /**
> >> +     * \german
> >> +     * Abspielgeräte können mehrere logische Kanäle anbieten, die vom Gerät
> >> +     * zusammengemixt werden. Ist dem nicht der Fall oder handelt es sich um
> >> +     * ein Aufnahmegerät, dann ist die Größe dieser Liste genau 1. Sie enthält
> >> +     * Elemente des Typs struct cdi_audio_stream.
> >> +     * \endgerman
> >> +     * \english
> >> +     * Play back devices may provide several logical streams which are mixed by
> >> +     * the device. If this is either not true or it is a recording device, the
> >> +     * list's size is exactly 1. It contains elements of type
> >> +     * struct cdi_audio_stream.
> >> +     * \endenglish
> >> +     */
> >> +    cdi_list_t streams;
> >
> > If you want to keep the restriction enforced and still have only one
> > device for everything, you could have a cdi_list_t playback_streams and
> > a struct cdi_audio_stream* record_stream, which may be NULL.
> 
> Maybe this is something for CDI/mixer if that path is chosen. I'm
> wondering now what does the mixing here on devices that don't do
> hardware mixing.

As Max stated in his initial description, that's a layer not addressed
by this patch. We can get that later. Instead of creating a solution
for hardware access, mixers, generalized driver communication and world
hunger at once (which has failed in the past year), I'd really love to
see _something_ working. If that means that I won't be able to play two
sounds at the same time for now - well, so be it. Better than not
having any sound for another year.

Don't get me wrong, I'm all for an OS independent mixer. But it
shouldn't be a requirement for getting the hardware drivers in.

Kevin