All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: alsa problems
Date: Tue, 28 Mar 2006 15:44:11 +0200	[thread overview]
Message-ID: <1143553451.13615.57.camel@localhost> (raw)
In-Reply-To: <s5hodzq7ktj.wl%tiwai@suse.de>

[-- 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 --]

  reply	other threads:[~2006-03-28 13:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28 12:10 alsa problems Johannes Berg
2006-03-28 13:08 ` Takashi Iwai
2006-03-28 13:11   ` Johannes Berg
2006-03-28 13:16     ` Takashi Iwai
2006-03-28 13:21       ` Johannes Berg
2006-03-28 13:36         ` Takashi Iwai
2006-03-28 13:44           ` Johannes Berg [this message]
2006-03-28 14:06             ` Takashi Iwai
2006-03-28 14:10               ` Johannes Berg
2006-03-28 14:21                 ` Takashi Iwai
2006-03-28 15:33                   ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1143553451.13615.57.camel@localhost \
    --to=johannes@sipsolutions.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.