All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: sylvain.bertrand@gmail.com
Cc: alsa-devel@alsa-project.org
Subject: Re: right way to enumerate pcm devices
Date: Wed, 13 Feb 2019 15:33:23 +0100	[thread overview]
Message-ID: <s5hva1n21xo.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190213141328.GA358@freedom>

On Wed, 13 Feb 2019 15:13:28 +0100,
sylvain.bertrand@gmail.com wrote:
> 
> On Wed, Feb 13, 2019 at 07:25:13AM +0100, Takashi Iwai wrote:
> > It's only the matter of alsa-lib card config.  Just due to heuristic
> > reason, the secondary device is assigned as iec958 as default.  There
> > are explicit whitelist setup in alsa-lib/src/conf/cards/USB-Audio.conf
> > for the card that behave differently.  You'd need to adjust
> > accordingly.
> 
> Tell me if I did understand you right:
> 
> I cannot trust the hint system to select proper pcm devices for, let's say the
> mic of my USB cam.

It can be seen rather as a bug in alsa-lib card config.  The card
config should be fixed to match with this badly behaving device.

> I would have to ignore "mostly" the configuration system (the major exception
> would be the default pcm device) and build myself the pcm devices from the info
> I can get from the hardware device (hardware mixing, input and/or output,
> number of channels/etc).

Or report the bug to get it fixed.

> I would have to cherry pick configuration defined pcm devices for specific
> modes, like surroundX, only if the "basic user" explicitely requests such modes.

... if you want to fix it by yourself, right.

> The advanced user should override the default pcm device if he/she wants to
> do/fix tricky sound thingies.

The advanced user should report the bug report, not ignore and work
around it, too :)


Takashi

> 
> ----
> 
> To summarize:
> 	- show always the pcm default
> 	- build custom pcm devices based on hardware info, and show them
> 	- for "special" modes, likes surroundX, show the related configuration
> 	  defined pcm devices only if the "basic" user want to fool around with
> 	  them.
> 
> -- 
> Sylvain
> 

  reply	other threads:[~2019-02-13 14:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12 12:33 right way to enumerate pcm devices sylvain.bertrand
2019-02-12 13:36 ` Takashi Iwai
2019-02-12 20:33   ` sylvain.bertrand
2019-02-13  6:25     ` Takashi Iwai
2019-02-13 14:13       ` sylvain.bertrand
2019-02-13 14:33         ` Takashi Iwai [this message]
2019-02-13 14:38         ` Jaroslav Kysela
2019-02-13 22:25         ` sylvain.bertrand
2019-02-13 22:43           ` sylvain.bertrand
     [not found]             ` <CA+Owze4OqfSystQ5ZNaF6sO+L-L-FceN5XBPJkqyYf7zjkp+GQ@mail.gmail.com>
2019-02-13 23:11               ` Fwd: " Joël Krähemann
2019-02-14 13:12                 ` sylvain.bertrand

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=s5hva1n21xo.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=sylvain.bertrand@gmail.com \
    /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.