alsa problems

alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Hi,

I continued writing the new driver for the apple machine sound stuff,
and I keep running into alsa bugs which is pretty frustrating.

1)
#include <sound/core.h>
doesn't compile because it requires sound/driver.h *before* it.

2)
snd_pcm_new_stream doesn't create the pcm devices when the pcm has
already been registered.
Since I don't know a priori which directions (playback/capture) my pcm
will support, I wanted to add the pcm, register it, and then add
substreams to it. No such luck, so now I have to register both
substreams (I can only support one in each direction anyway) without
knowing if they can ever be used...

3)
No way to get rid of some kinds of resources, like pcms...

Concluding, I'd say that there ought to be some effort to make alsa more
dynamic with the kinds of devices you have in card...

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: alsa problems

[Takashi Iwai]

At Tue, 28 Mar 2006 14:10:35 +0200,
Johannes Berg wrote:
> 
> Hi,
> 
> I continued writing the new driver for the apple machine sound stuff,
> and I keep running into alsa bugs which is pretty frustrating.

They are no called as bugs.

> 1)
> #include <sound/core.h>
> doesn't compile because it requires sound/driver.h *before* it.

Yes.  And what's the point?

> 2)
> snd_pcm_new_stream doesn't create the pcm devices when the pcm has
> already been registered.
> Since I don't know a priori which directions (playback/capture) my pcm
> will support, I wanted to add the pcm, register it, and then add
> substreams to it. No such luck, so now I have to register both
> substreams (I can only support one in each direction anyway) without
> knowing if they can ever be used...

I don't understand what's the problem.  You can create an empty PCM
via snd_pcm_new(), then add each stream, playback or capture, can be
assigned appropriately via snd_pcm_new_stream() later on.

If you want to add _substreams_ dynamically, then it's not allowed.
It'd be relatively easy to extend it although I rarely see the reason
to do it.

> 3)
> No way to get rid of some kinds of resources, like pcms...

It can.  Call snd_device_free().


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

On Tue, 2006-03-28 at 15:08 +0200, Takashi Iwai wrote:

> > 1)
> > #include <sound/core.h>
> > doesn't compile because it requires sound/driver.h *before* it.
> 
> Yes.  And what's the point?

Well, that's pretty dumb. If it requires sound/driver.h it could just as
well include it itself.

> I don't understand what's the problem.  You can create an empty PCM
> via snd_pcm_new(), then add each stream, playback or capture, can be
> assigned appropriately via snd_pcm_new_stream() later on.

Right.
snd_pcm_new()
snd_device_register(card, pcm)
snd_pcm_new_stream(...)   <--- this stream never shows up as a chardev!!

> It can.  Call snd_device_free().

Hah ok. I didn't realize pcms were really just device thingies since
they have so many extra functions.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: alsa problems

[Takashi Iwai]

At Tue, 28 Mar 2006 15:11:46 +0200,
Johannes Berg wrote:
> 
> [1  <text/plain (quoted-printable)>]
> On Tue, 2006-03-28 at 15:08 +0200, Takashi Iwai wrote:
> 
> > > 1)
> > > #include <sound/core.h>
> > > doesn't compile because it requires sound/driver.h *before* it.
> > 
> > Yes.  And what's the point?
> 
> Well, that's pretty dumb. If it requires sound/driver.h it could just as
> well include it itself.

It's so in order to process the many compatible wrappers.
You'll see how many things are hidden there in include/adriver.h.

> > I don't understand what's the problem.  You can create an empty PCM
> > via snd_pcm_new(), then add each stream, playback or capture, can be
> > assigned appropriately via snd_pcm_new_stream() later on.
> 
> Right.
> snd_pcm_new()
> snd_device_register(card, pcm)
> snd_pcm_new_stream(...)   <--- this stream never shows up as a chardev!!

Why do you need to register the device before creating instances?
It means that apps are allowed to access the driver even though it's
not ready.   This looks like a wrong design.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Tue, 2006-03-28 at 15:16 +0200, Takashi Iwai wrote:

> Why do you need to register the device before creating instances?
> It means that apps are allowed to access the driver even though it's
> not ready.   This looks like a wrong design.

Because the pcm is created by my i2s bus driver (which knows it can only
have one pcm per i2s bus).

Then once codecs are discovered, they attach, and the streams are
created.

Right now it's even more broken requiring me to create both the playback
and capture stream without knowing if there's anything on the bus that
can handle it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: alsa problems

[Takashi Iwai]

At Tue, 28 Mar 2006 15:21:22 +0200,
Johannes Berg wrote:
> 
> [1  <text/plain (quoted-printable)>]
> On Tue, 2006-03-28 at 15:16 +0200, Takashi Iwai wrote:
> 
> > Why do you need to register the device before creating instances?
> > It means that apps are allowed to access the driver even though it's
> > not ready.   This looks like a wrong design.
> 
> Because the pcm is created by my i2s bus driver (which knows it can only
> have one pcm per i2s bus).

What do you mean one pcm?  One PCM substream, one-directional stream,
or both one pcm instance containing playback and capture streams?

> Then once codecs are discovered, they attach, and the streams are
> created.

The question is rather the flow of creation.
Usually, the registration occurs at the very last of initialization
stage, i.e. all devices are probed and initialized to be ready for
use.  Then the driver calls register function.

If the registration _must_ be done dynamically, one by one, the
situation becomes a bit more complicated.  It's not only to the driver
but to the user-space things.

> Right now it's even more broken requiring me to create both the playback
> and capture stream without knowing if there's anything on the bus that
> can handle it.

You don't have to create an empty PCM, but create a PCM on demand, as
usbaudio.c does.  It doesn't create both streams.

The point is only that the register is done later.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2006-03-28 at 15:36 +0200, Takashi Iwai wrote:

> > Because the pcm is created by my i2s bus driver (which knows it can only
> > have one pcm per i2s bus).
> 
> What do you mean one pcm?  One PCM substream, one-directional stream,
> or both one pcm instance containing playback and capture streams?

I can have at most one pcm instance containing one playback and one
capture stream per i2s bus.

> The question is rather the flow of creation.
> Usually, the registration occurs at the very last of initialization
> stage, i.e. all devices are probed and initialized to be ready for
> use.  Then the driver calls register function.
> 
> If the registration _must_ be done dynamically, one by one, the
> situation becomes a bit more complicated.  It's not only to the driver
> but to the user-space things.

Yes. It must be done dynamically.

> > Right now it's even more broken requiring me to create both the playback
> > and capture stream without knowing if there's anything on the bus that
> > can handle it.
> 
> You don't have to create an empty PCM, but create a PCM on demand, as
> usbaudio.c does.  It doesn't create both streams.

Right.
Let me explain the control flow:

First, i2s busses are discovered, but no pcm instances created for them
yet.

Then, codecs are discovered, and each on registers with the i2s bus it
sits on. At that point, the codec could support input only, and it
announces this to the i2s bus. Thus, the i2s bus creates a pcm with just
a capture stream, and registers it.

Now, another codec is discovered, and it is on the same i2s bus, but
supports playback and capture. Now, my i2s layer handles switching
between which one of them gets to capture, so that's fine, but when I
now try to add a playback stream to my pcm, this playback stream never
shows up.

[the actual situation is slightly different, but this serves well to
illustrate it and might actually happen this way in the future]

Now, I cannot defer registration of the pcm until the second codec is
discovered because there's no way to know if a second codec even exists,
and even if it exists if the user compiled the module for it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: alsa problems

[Takashi Iwai]

At Tue, 28 Mar 2006 15:44:11 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-03-28 at 15:36 +0200, Takashi Iwai wrote:
> 
> > > Because the pcm is created by my i2s bus driver (which knows it can only
> > > have one pcm per i2s bus).
> > 
> > What do you mean one pcm?  One PCM substream, one-directional stream,
> > or both one pcm instance containing playback and capture streams?
> 
> I can have at most one pcm instance containing one playback and one
> capture stream per i2s bus.
> 
> > The question is rather the flow of creation.
> > Usually, the registration occurs at the very last of initialization
> > stage, i.e. all devices are probed and initialized to be ready for
> > use.  Then the driver calls register function.
> > 
> > If the registration _must_ be done dynamically, one by one, the
> > situation becomes a bit more complicated.  It's not only to the driver
> > but to the user-space things.
> 
> Yes. It must be done dynamically.
> 
> > > Right now it's even more broken requiring me to create both the playback
> > > and capture stream without knowing if there's anything on the bus that
> > > can handle it.
> > 
> > You don't have to create an empty PCM, but create a PCM on demand, as
> > usbaudio.c does.  It doesn't create both streams.
> 
> Right.
> Let me explain the control flow:
> 
> First, i2s busses are discovered, but no pcm instances created for them
> yet.
> 
> Then, codecs are discovered, and each on registers with the i2s bus it
> sits on. At that point, the codec could support input only, and it
> announces this to the i2s bus. Thus, the i2s bus creates a pcm with just
> a capture stream, and registers it.
> 
> Now, another codec is discovered, and it is on the same i2s bus, but
> supports playback and capture. Now, my i2s layer handles switching
> between which one of them gets to capture, so that's fine, but when I
> now try to add a playback stream to my pcm, this playback stream never
> shows up.
> 
> [the actual situation is slightly different, but this serves well to
> illustrate it and might actually happen this way in the future]
> 
> Now, I cannot defer registration of the pcm until the second codec is
> discovered because there's no way to know if a second codec even exists,
> and even if it exists if the user compiled the module for it.

Hm, it's indeed a complex situaton.

A relatively easy workaround is to create two PCM instances, each of
which is dedicated for only a single direction.  Then you can define
appropriate configuration in alsa-lib to choose the right PCM number.
The drawbacks are about the kernel OSS emulator, as usual.

Alternatively, we can create a new function,
e.g. snd_pcm_register_stream(), for doing what snd_pcm_dev_register()
does for a single stream.  It's an exception only for PCM which may
have multiple device files.


I have a rough design of new PCM middle layer in my head to reduce
snd_pcm struct, and it would work fine in your case.  Nevertheless,
it's still a vaporware :)


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Tue, 2006-03-28 at 16:06 +0200, Takashi Iwai wrote:

> A relatively easy workaround is to create two PCM instances, each of
> which is dedicated for only a single direction.  Then you can define
> appropriate configuration in alsa-lib to choose the right PCM number.
> The drawbacks are about the kernel OSS emulator, as usual.

Ok I guess that would work. But my current workaround with just defining
both directions and refusing access to those that don't work seems to do
fine too.

> Alternatively, we can create a new function,
> e.g. snd_pcm_register_stream(), for doing what snd_pcm_dev_register()
> does for a single stream.  It's an exception only for PCM which may
> have multiple device files.

Yes, that'd be good to have, indeed it would essentially be a code move
and the old code would call the new function.

> I have a rough design of new PCM middle layer in my head to reduce
> snd_pcm struct, and it would work fine in your case.  Nevertheless,
> it's still a vaporware :)

Heh :) Make sure to include some compressed content stuff, it could just
be a different format or something...

If you post a braindump I'll take a look and comment on it :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

Re: alsa problems

[Takashi Iwai]

At Tue, 28 Mar 2006 16:10:36 +0200,
Johannes Berg wrote:
> 
> On Tue, 2006-03-28 at 16:06 +0200, Takashi Iwai wrote:
> 
> > A relatively easy workaround is to create two PCM instances, each of
> > which is dedicated for only a single direction.  Then you can define
> > appropriate configuration in alsa-lib to choose the right PCM number.
> > The drawbacks are about the kernel OSS emulator, as usual.
> 
> Ok I guess that would work. But my current workaround with just defining
> both directions and refusing access to those that don't work seems to do
> fine too.

Ah, that sounds OK, too.  The driver can return -ENOENT, so basically
it looks same from the user-space as if there is no real device file.

> > Alternatively, we can create a new function,
> > e.g. snd_pcm_register_stream(), for doing what snd_pcm_dev_register()
> > does for a single stream.  It's an exception only for PCM which may
> > have multiple device files.
> 
> Yes, that'd be good to have, indeed it would essentially be a code move
> and the old code would call the new function.

OK, I'll pass you a patch later.
I think, however, this won't go to 2.6.17 kernel since we have no
caller yet.

> > I have a rough design of new PCM middle layer in my head to reduce
> > snd_pcm struct, and it would work fine in your case.  Nevertheless,
> > it's still a vaporware :)
> 
> Heh :) Make sure to include some compressed content stuff, it could just
> be a different format or something...

A good point.  The handling of compressed formats is still under
considration.  Any comments about preferred behavior are welcome.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: alsa problems

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Tue, 2006-03-28 at 16:21 +0200, Takashi Iwai wrote:

> Ah, that sounds OK, too.  The driver can return -ENOENT, so basically
> it looks same from the user-space as if there is no real device file.

Good point. I'm returning -ENODEV right now, but ENOENT might be
misleading, the open can also fail in the same way if the codec chips
behind the i2s bus aren't usable at the moment.

> OK, I'll pass you a patch later.
> I think, however, this won't go to 2.6.17 kernel since we have no
> caller yet.

No worries. I'll keep the current workaround, I'm not aiming for kernel
inclusion in the short term. Thus we can keep your patch on the queue
until my driver enters the queue :)

> A good point.  The handling of compressed formats is still under
> considration.  Any comments about preferred behavior are welcome.

Will think about it and send another mail.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]