On Wed, May 12, 2010 at 05:01:57PM +0800, Takashi Iwai wrote:
> At Wed, 12 May 2010 16:39:50 +0800,
> Wu Fengguang wrote:
> >
> > On Wed, May 12, 2010 at 04:03:43PM +0800, Takashi Iwai wrote:
> > > At Wed, 12 May 2010 09:29:57 +0200 (CEST),
> > > Jaroslav Kysela wrote:
> > > >
> > > > On Wed, 12 May 2010, Wu Fengguang wrote:
> > > >
> > > > > Reserve 32 minor numbers for PCM playback devices.
> > > > >
> > > > > The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> > > > > indices 3, 7, 8. Among which the device 8's minor number will be
> > > > > overlapped with the first capture device's minor number in the current
> > > > > static minor number allocation scheme.
> > > > >
> > > > > Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> > > > > the increasing number of PCM devices.
> > > >
> > > > I don't agree to have only 4 slots for soundcards in the static minor
> > > > numbering. Maybe the driver should be converted to use subdevices or we
> > > > might drop the static minor number allocation at all (it might have only
> > > > impact for old distros).
> >
> > Jaroslav, will there be so many sound cards in one system?
>
> In the old time, yes. Now we have less and less PCI slots.
> In theory, we may have lots of USB audio devices, though :)
>
> Another possible solution would be to change the minor number
> assignment to a really dynamic one. So far, due to legacy /dev/aload
> and co, we have some static restriction per card basis.
Another simple option is to "borrow" 2 slots from one of
- SNDRV_MINOR_HWDEP : has 4 slots
- SNDRV_MINOR_RAWMIDI : has 8 slots
- SNDRV_MINOR_PCM_CAPTURE: has 8 slots
What do you think?
>
> > > Dropping such a base feature is really no good option. Better to give
> > > simply an error for more than 8 PCMs in such a case, IMO.
> >
> > Agreed.
> >
> > > I also wonder whether having 4 individual PCMs is a way to go. We may
> > > have PCM substreams, if any. OTOH, the current IEC958 stream
> > > assignment mechanism doesn't consider multiple substreams well, e.g.
> > > we have no proper way to match the IEC958 status bits control to a PCM
> > > substream.
> >
> > Hmm, what if there are two monitors attached, each want to play a
> > different music track?
>
> PCM substreams are really independent from each other. So,
> technically seen, substreams are feasible.
>
> > I think the 3 HDMI devices are inherently independent. Each one can
> > have different hw rates, bits, and speaker allocation. And if
> > implemented as PCM substreams, how can the user space specify "please
> > play this music on this monitor"? AFAIK the windows driver also
> > exports 3 independent HDMI playback devices.
>
> Yeah, as mentioned, SPDIF status mapping isn't provided properly as
> is. Thus using PCM substreams may give some confusion indeed.
Can I ask a dumb question? Currently I select the target playback
device with the -D option:
speaker-test -Dhw:0,3
How can I do the job when PCM substreams are used?
Thanks,
Fengguang
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
