RFC: Appropriate device detection for Wine

RFC: Appropriate device detection for Wine

[Jeremy White]

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

Hi All,

I was hoping to get some advice on the proper use of Alsalib
within Wine, particularly with respect to
device detection and enumeration.

Wine has a need to provide a list of all available
PCM (playback and capture) devices back to our
clients (a Windows program).

Right now, Wine has a brute force
scan process (iterate 0-5 in cards, always use dev 0).

I've implemented a program that represents what I think
is the 'right' way for Wine to perform this scan.
Note that this code is just for the default case where
the user hasn't explicitly specified a device
name; Wine will still allow the user to override this
scan with an explicit device name such as file:/tmp/blat

The basic approach I take is as follows:
   Use snd_card_next to iterate cards;
within cards, use snd_ctl_pcm_next_device
to iterate devices.

I jump through a few hoops to detect and respect
a specification of ALSA_CTL_CARD or ALSA_CARD, etc,

Now I've deluded myself into thinking this is a
careful, rigorous implementation.

Thoughts?  Comments?  Tactfully worded puncturing of
my delusions <grin>?

Thanks,

Jeremy

[-- Attachment #2: alsascan.c --]
[-- Type: text/x-csrc, Size: 14613 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <alsa/asoundlib.h>

/* Macros to mock up Wine compatibility */
#define ERR printf
#define WARN printf
#define TRACE printf
#define TRUE 1
#define FALSE 0

#define ALSA_RETURN_ONFAIL(mycall)                                      \
{                                                                       \
    int rc = mycall;                                                    \
    if ((rc) < 0)                                                       \
    {                                                                   \
        ERR("%s failed:  %s(%d)\n", #mycall, snd_strerror(rc), rc);     \
        return(rc);                                                     \
    }                                                                   \
}

/*----------------------------------------------------------------------------
**  ALSA_AddPlaybackDevice
**
**      Add a given Alsa device to Wine's internal list of Playback
**  devices.
**
**  Parameters:
**      ctl         Control handle; can be NULL
**      pcm         PCM handle, must be ! NULL
**      isdefault   Flag, if !0, indicates this device matches Alsa's
**                  definition of the default PCM device
**
**--------------------------------------------------------------------------*/
static int ALSA_AddPlaybackDevice(snd_ctl_t *ctl, snd_pcm_t *pcm, int isdefault)
{
    snd_pcm_info_t *infop;

    ALSA_RETURN_ONFAIL(snd_pcm_info_malloc(&infop));
    ALSA_RETURN_ONFAIL(snd_pcm_info(pcm, infop));

    /* FIXME:  Add real implementation here */
    printf("Playback [pcm %s/ctl %s|id %s|", snd_pcm_name(pcm), ctl ? snd_ctl_name(ctl) : "(none)", snd_pcm_info_get_id(infop));
    printf("name %s|%s", snd_pcm_info_get_name(infop), isdefault ? "Default" : "Not default");
    printf("]\n");

    snd_pcm_info_free(infop);

    return 0;
}

/*----------------------------------------------------------------------------
**  ALSA_AddCaptureDevice
**
**      Add a given Alsa device to Wine's internal list of Capture
**  devices.
**
**  Parameters:
**      ctl         Control handle; can be NULL
**      pcm         PCM handle, must be ! NULL
**      isdefault   Flag, if !0, indicates this device matches Alsa's
**                  definition of the default PCM device
**
**--------------------------------------------------------------------------*/
static int ALSA_AddCaptureDevice(snd_ctl_t *ctl, snd_pcm_t *pcm, int isdefault)
{
    snd_pcm_info_t *infop;

    ALSA_RETURN_ONFAIL(snd_pcm_info_malloc(&infop));
    ALSA_RETURN_ONFAIL(snd_pcm_info(pcm, infop));

    /* FIXME:  Add real implementation here */
    printf("Capture  [pcm %s/ctl %s|id %s|", snd_pcm_name(pcm), ctl ? snd_ctl_name(ctl) : "(none)", snd_pcm_info_get_id(infop));
    printf("name %s|%s", snd_pcm_info_get_name(infop), isdefault ? "Default" : "Not default");
    printf("]\n");

    snd_pcm_info_free(infop);

    return 0;
}

/*----------------------------------------------------------------------------
**  ALSA_CheckEnvironment
**
**      Given an Alsa style configuration node, scan its subitems
**  for environment variable names, and use them to find an override,
**  if appropriate.
**      This is essentially a long and convolunted way of doing:
**          getenv("ALSA_CARD") 
**          getenv("ALSA_CTL_CARD") 
**          getenv("ALSA_PCM_CARD") 
**          getenv("ALSA_PCM_DEVICE") 
**
**  The output value is set with the atoi() of the first environment
**  variable found to be set.
**--------------------------------------------------------------------------*/
static void ALSA_CheckEnvironment(snd_config_t *node, int *outvalue)
{
    snd_config_iterator_t iter;

    for (iter = snd_config_iterator_first(node); 
         iter != snd_config_iterator_end(node);
         iter = snd_config_iterator_next(iter))
    {
        snd_config_t *leaf = snd_config_iterator_entry(iter);
        if (snd_config_get_type(leaf) == SND_CONFIG_TYPE_STRING)
        {
            const char *value;
            if (snd_config_get_string(leaf, &value) >= 0)
            {
                char *p = getenv(value);
                if (p)
                {
                    *outvalue = atoi(p);
                    return;
                }
            }
        }
    }
}

/*----------------------------------------------------------------------------
**  ALSA_DefaultDevices
**
**      Jump through Alsa style hoops to (hopefully) properly determine
**  Alsa defaults for CTL Card #, as well as for PCM Card + Device #.
**  We'll also find out if the user has set any of the environment
**  variables that specify we're to use a specific card or device.
**
**  Parameters:
**      plugflag        Whether to use the plugin device or not;
**                      essentially switches the pcm device name from
**                      "hw" to "plughw".
**      defctlcard      If !NULL, will hold the ctl card number given
**                      by the ALSA config as the default
**      defpcmcard      If !NULL, default pcm card #
**      defpcmdev       If !NULL, default pcm device #
**      fixedctlcard    If !NULL, and the user set the appropriate
**                          environment variable, we'll set to the
**                          card the user specified.
**      fixedpcmcard    If !NULL, and the user set the appropriate
**                          environment variable, we'll set to the
**                          card the user specified.
**      fixedpcmdev     If !NULL, and the user set the appropriate
**                          environment variable, we'll set to the
**                          device the user specified.
**
**  Returns:  0 on success, < 0 on failiure
**--------------------------------------------------------------------------*/
static int ALSA_DefaultDevices(int plugflag, 
            long *defctlcard,
            long *defpcmcard, long *defpcmdev,
            int *fixedctlcard, 
            int *fixedpcmcard, int *fixedpcmdev)
{
    snd_config_t   *configp;
    char pcmsearch[256];

    ALSA_RETURN_ONFAIL(snd_config_update());

    if (defctlcard)
        if (snd_config_search(snd_config, "defaults.ctl.card", &configp) >= 0)
            snd_config_get_integer(configp, defctlcard);

    if (defpcmcard)
        if (snd_config_search(snd_config, "defaults.pcm.card", &configp) >= 0)
            snd_config_get_integer(configp, defpcmcard);

    if (defpcmdev)
        if (snd_config_search(snd_config, "defaults.pcm.device", &configp) >= 0)
            snd_config_get_integer(configp, defpcmdev);


    if (fixedctlcard)
    {
        if (snd_config_search(snd_config, "ctl.hw.@args.CARD.default.vars", &configp) >= 0)
            ALSA_CheckEnvironment(configp, fixedctlcard);
    }

    if (fixedpcmcard)
    {
        sprintf(pcmsearch, "pcm.%s.@args.CARD.default.vars", plugflag ? "plughw" : "hw");
        if (snd_config_search(snd_config, pcmsearch, &configp) >= 0)
            ALSA_CheckEnvironment(configp, fixedpcmcard);
    }

    if (fixedpcmdev)
    {
        sprintf(pcmsearch, "pcm.%s.@args.DEV.default.vars", plugflag ? "plughw" : "hw");
        if (snd_config_search(snd_config, pcmsearch, &configp) >= 0)
            ALSA_CheckEnvironment(configp, fixedpcmdev);
    }

    return 0;
}


/*----------------------------------------------------------------------------
**  ALSA_ScanDevices
**
**      Iterate through all discoverable ALSA cards, searching
**  for usable PCM devices.
**
**  Parameters:
**      plugflag        Whether to use the plugin device or not;
**                      essentially switches the pcm device name from
**                      "hw" to "plughw".
**      defctlcard      Alsa's notion of the default ctl card.
**      defpcmcard         . pcm card 
**      defpcmdev          . pcm device 
**      fixedctlcard    If not -1, then gives the value of ALSA_CTL_CARD
**                          or equivalent environment variable
**      fixedpcmcard    If not -1, then gives the value of ALSA_PCM_CARD
**                          or equivalent environment variable
**      fixedpcmdev     If not -1, then gives the value of ALSA_PCM_DEVICE
**                          or equivalent environment variable
**
**  Returns:  0 on success, < 0 on failiure
**--------------------------------------------------------------------------*/
static int ALSA_ScanDevices(int plugflag, 
        long defctlcard, long defpcmcard, long defpcmdev,
        int fixedctlcard, int fixedpcmcard, int fixedpcmdev)
{
    int card = fixedpcmcard;

    /*------------------------------------------------------------------------
    ** Loop through all available cards
    **----------------------------------------------------------------------*/
    if (card == -1)
        snd_card_next(&card);

    for (; card != -1; snd_card_next(&card))
    {
        char ctlname[256];
        snd_ctl_t *ctl;
        int rc;
        int device;

        /*--------------------------------------------------------------------
        ** Try to open a ctl handle; Wine doesn't absolutely require one,
        **  but it does allow for volume control and for device scanning
        **------------------------------------------------------------------*/
        sprintf(ctlname, "hw:%d", fixedctlcard == -1 ? card : fixedctlcard);
        rc = snd_ctl_open(&ctl, ctlname, 0);
        if (rc < 0)
        {
            ctl = NULL;
            WARN("Unable to open an alsa ctl for [%s] (pcm card %d): %s; not scanning devices\n", 
                    ctlname, card, snd_strerror(rc));
            if (fixedpcmdev == -1)
                fixedpcmdev = 0;
        }

        /*--------------------------------------------------------------------
        ** Loop through all available devices on this card
        **------------------------------------------------------------------*/
        device = fixedpcmdev;
        if (device == -1)
            snd_ctl_pcm_next_device(ctl, &device);

        for (; device != -1; snd_ctl_pcm_next_device(ctl, &device))
        {
            char pcmname[256];
            snd_pcm_t *pcm;

            /*----------------------------------------------------------------
            ** See if it's a valid playback device 
            **--------------------------------------------------------------*/
            sprintf(pcmname, "%s:%d,%d", plugflag ? "plughw" : "hw", card, device);
            rc = snd_pcm_open(&pcm, pcmname, SND_PCM_STREAM_PLAYBACK, 0);
            if (rc >= 0)
            {
                if (defctlcard == card && defpcmcard == card && defpcmdev == device)
                    ALSA_AddPlaybackDevice(ctl, pcm, TRUE);
                else
                    ALSA_AddPlaybackDevice(ctl, pcm, FALSE);

                snd_pcm_close(pcm);
            }
            else
            {
                TRACE("Device [%s] not suitable for playback: %s\n",
                        pcmname, snd_strerror(rc));
            }

            /*----------------------------------------------------------------
            ** See if it's a valid capture device 
            **--------------------------------------------------------------*/
            rc = snd_pcm_open(&pcm, pcmname, SND_PCM_STREAM_CAPTURE, 0);
            if (rc >= 0)
            {
                if (defctlcard == card && defpcmcard == card && defpcmdev == device)
                    ALSA_AddCaptureDevice(ctl, pcm, TRUE);
                else
                    ALSA_AddCaptureDevice(ctl, pcm, FALSE);

                snd_pcm_close(pcm);
            }
            else
            {
                TRACE("Device [%s] not suitable for capture: %s\n",
                        pcmname, snd_strerror(rc));
            }

            /*----------------------------------------------------------------
            ** If the user has set environment variables such that
            **  we're pegged to a specific device (or if we've got no
            **  ctl device), then break out of the device scan loop
            **--------------------------------------------------------------*/
            if (fixedpcmdev != -1)
                break;
        }

        if (ctl)
            snd_ctl_close(ctl);

        /*--------------------------------------------------------------------
        ** If the user has set env variables such that we're pegged to
        **  a specific card, then break after we've examined it
        **------------------------------------------------------------------*/
        if (fixedpcmcard != -1)
            break;
    }

    return 0;

}

/*----------------------------------------------------------------------------
** ALSA_PerformDefaultScan
**  Perform the basic default scanning for devices within ALSA.
**  The hope is that this routine implements a 'correct' 
**  scanning algorithm from the Alsalib point of view.
**
**      Note that Wine, overall, has other mechanisms to
**  override and specify exact CTL and PCM device names,
**  but this routine is imagined as the default that
**  99% of users will use.
**
**      The basic algorithm is simple:
**  Use snd_card_next to iterate cards; within cards, use
**  snd_ctl_pcm_next_device to iterate through devices.
**
**      We add a little complexity by taking into consideration
**  environment variables such as ALSA_CARD (et all), and by
**  detecting when a given device matches the default specified
**  by Alsa.
**
**  Parameters:
**      plugflag        If !0, indicates we should use the plug:hw
**                      PCM interface, rather than the hw interface.
**                      The plug:hw interface performs automatic
**                      rate conversion and a bunch of other magic
**                      things that can be quite handy.
**
**  Returns:
**      0   on succes
**
**  Side Effects:
**      Invokes the ALSA_AddXXXDevice functions on valid
**  looking devices
**--------------------------------------------------------------------------*/
static int ALSA_PerformDefaultScan(int plugflag)
{
    long defctlcard = -1, defpcmcard = -1, defpcmdev = -1;
    int fixedctlcard = -1, fixedpcmcard = -1, fixedpcmdev = -1;
    int rc;
   
    rc = ALSA_DefaultDevices(plugflag, &defctlcard, &defpcmcard, &defpcmdev, 
            &fixedctlcard, &fixedpcmcard, &fixedpcmdev);
    if (rc)
        return(rc);

    return(ALSA_ScanDevices(plugflag, defctlcard, defpcmcard, defpcmdev, fixedctlcard, fixedpcmcard, fixedpcmdev));
}

int main(void)
{
    ALSA_PerformDefaultScan(0);
    ALSA_PerformDefaultScan(1);
    ALSA_RETURN_ONFAIL(snd_config_update_free_global());
    return 0;
}

Re: RFC: Appropriate device detection for Wine

[Jaroslav Kysela]

On Mon, 6 Jun 2005, Jeremy White wrote:

> Thoughts?  Comments?  Tactfully worded puncturing of
> my delusions <grin>?

The right way is to use snd_names_list() and snd_names_list_free()
functions (available from 1.0.9). Simply look for words like Playback
Capture and Duplex in the comment member to determine the stream direction.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine

[Jeremy White]

Jaroslav Kysela wrote:
> On Mon, 6 Jun 2005, Jeremy White wrote:
> 
> 
>>Thoughts?  Comments?  Tactfully worded puncturing of
>>my delusions <grin>?
> 
> 
> The right way is to use snd_names_list() and snd_names_list_free()
> functions (available from 1.0.9). Simply look for words like Playback
> Capture and Duplex in the comment member to determine the stream direction.

I don't think we can mandate 1.0.9 of Alsalib; that's more
modern than what most users have.

Further, given that I have yet to run into a system
with a properly set up alsa.conf, I find it highly
unlikely that people will have well configured asound.names
files any time soon.

Cheers,

Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine

[Jaroslav Kysela]

On Tue, 7 Jun 2005, Jeremy White wrote:

> Jaroslav Kysela wrote:
> > On Mon, 6 Jun 2005, Jeremy White wrote:
> > 
> > 
> >>Thoughts?  Comments?  Tactfully worded puncturing of
> >>my delusions <grin>?
> > 
> > 
> > The right way is to use snd_names_list() and snd_names_list_free()
> > functions (available from 1.0.9). Simply look for words like Playback
> > Capture and Duplex in the comment member to determine the stream direction.
> 
> I don't think we can mandate 1.0.9 of Alsalib; that's more
> modern than what most users have.
> 
> Further, given that I have yet to run into a system
> with a properly set up alsa.conf, I find it highly
> unlikely that people will have well configured asound.names
> files any time soon.

Yes, but you should use the new API (use dlopen/dlsym for
snd_names_list/snd_names_list_free to let your code work with older 
alsa-lib) and provide fallback when the symbols don't exist or the list 
of devices is empty.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine

[Jeremy White]

> Yes, but you should use the new API (use dlopen/dlsym for
> snd_names_list/snd_names_list_free to let your code work with older 
> alsa-lib) and provide fallback when the symbols don't exist or the list 
> of devices is empty.

Fair enough; is it now the case that snd_names_list is considered
the canonical list of Alsa devices?  If found, there is no need
to check environment variables or anything else?

Cheers,

Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Jeremy White]

Okay,

So now I have a patch for Wine that very nicely
has Wine scanning for all cards and devices.  It
even probes for devices that behave badly
(e.g. my winmodem) and strips them out.

But I still have one device on my laptop;
card 0, device 4, that simply does not work
(see details below).

It seems to 'smell' right, but when data is
written to it, the buffer is never emptied.
Writing a sound file to it with aplay hangs
indefinitely; using pcm fills the sound buffer
and then blocks indefinitely.

So I'd like some advice:  Have I just been utterly
unrealistic in trying to scan for all PCM devices
on all cards?  Should I only report device 0 on each
card by default, and require the user to explicitly
request alternate devices?  Is there some way I can
detect that this device is psycho and automatically
strip it out?  What the heck is device 4 on my card?

Any/all advice appreciated.

Thanks,

Jeremy

p.s. Some details on sound card, let me know if more
is relevant:

releveant lspc -v snippet:


00000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
         Subsystem: Dell: Unknown device 011d
         Flags: bus master, medium devsel, latency 0, IRQ 7
         I/O ports at b800 [size=256]
         I/O ports at bc40 [size=64]
         Memory at f4fff800 (32-bit, non-prefetchable) [size=512]
         Memory at f4fff400 (32-bit, non-prefetchable) [size=256]
         Capabilities: [50] Power Management version 2


jertop:/proc/asound/card0/pcm4p# cat /proc/asound/card0/pcm4p/info
card: 0
device: 4
subdevice: 0
stream: PLAYBACK
id: Intel ICH - IEC958
name: Intel 82801DB-ICH4 - IEC958
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1



cat /proc/asound/devices
jertop:/# cat /proc/asound/devices
   0: [0- 0]: ctl
  20: [0- 4]: digital audio playback
  27: [0- 3]: digital audio capture
  26: [0- 2]: digital audio capture
  25: [0- 1]: digital audio capture
  16: [0- 0]: digital audio playback
  24: [0- 0]: digital audio capture
  33:       : timer
  32: [1- 0]: ctl
  48: [1- 0]: digital audio playback
  56: [1- 0]: digital audio capture


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Clemens Ladisch]

Jeremy White wrote:
> But I still have one device on my laptop;
> card 0, device 4, that simply does not work
> (see details below).
> name: Intel 82801DB-ICH4 - IEC958

This is the SPDIF output.

I don't know what the problem is, especially if the PCM output _does_
work.  Does your machine actually have an SPDIF output?

> So I'd like some advice:  Have I just been utterly
> unrealistic in trying to scan for all PCM devices
> on all cards?

No, you cannot do more.  The user has to decide which device to use.

> Is there some way I can detect that this device is psycho and
> automatically strip it out?

There are many reason why a device could be temporarily unavailable,
so Wine shouldn't try to be too intelligent. :-)


HTH
Clemens



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Jeremy White]

> This is the SPDIF output.
> 
> I don't know what the problem is, especially if the PCM output _does_
> work.  Does your machine actually have an SPDIF output?

No, I don't believe it does; it's a Dell Latitude D600 notebook.

> 
> 
>>So I'd like some advice:  Have I just been utterly
>>unrealistic in trying to scan for all PCM devices
>>on all cards?
> 
> 
> No, you cannot do more.  The user has to decide which device to use.

Yah.  I'm feeling a bit stuck; the Wine regression tests require
that all discovered devices pass a very basic set of tests.

So I've made a change that I think is a Good Thing (TM),
but it doesn't pass the regression tests...

> 
> 
>>Is there some way I can detect that this device is psycho and
>>automatically strip it out?
> 
> 
> There are many reason why a device could be temporarily unavailable,
> so Wine shouldn't try to be too intelligent. :-)

Good point :-/.

Thanks,

Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Takashi Iwai]

At Mon, 13 Jun 2005 07:23:56 -0500,
Jeremy White wrote:
> 
> >>So I'd like some advice:  Have I just been utterly
> >>unrealistic in trying to scan for all PCM devices
> >>on all cards?
> > 
> > 
> > No, you cannot do more.  The user has to decide which device to use.
> 
> Yah.  I'm feeling a bit stuck; the Wine regression tests require
> that all discovered devices pass a very basic set of tests.

Accessing SPDIF device won't work unless you set up some controls
properly beforehand.  Usually SPDIF devices are accessed via "spdif"
(or "iec958") PCM, which will do this job automatically.

> So I've made a change that I think is a Good Thing (TM),
> but it doesn't pass the regression tests...

In most cases, secondary (or later) devices are _not_ supposed to work
by the direct access.  Many of them are designed for special use.

I'd recommend to list up only the card names, and try to use either
"default:X" or "plughw:X" (the former is preferred, but not available
in the older version).


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Jeremy White]

> I'd recommend to list up only the card names, and try to use either
> "default:X" or "plughw:X" (the former is preferred, but not available
> in the older version).

Wait; I worry that I misunderstand the use of 'default'.

Is there a thread or FM I should go read to fully understand?

That is, my understanding is that the default key is used
so that an end user just tells his or her sound app
to write to a 'defaults' device, and then Alsa worries
about mapping that to the correct device.

However, in the case of Wine, my fundamental mission
at initialization time is to provide a credible and
useful list of sound devices back to the application,
so the application can pick.  (At the same time, I need
to report which of those choices is the default, and
report that back to the application as well; I try to
do that via the alsa config apis).

But my first misunderstanding was that I thought there
was just one default device, not one that can be
iterated per card.  Does default:X simply get mapped
to one of either 'hw:X' or 'plughw:X' (or whatnot) based
on user preference?

Thanks,

Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Takashi Iwai]

At Mon, 13 Jun 2005 09:00:22 -0500,
Jeremy White wrote:
> 
> > I'd recommend to list up only the card names, and try to use either
> > "default:X" or "plughw:X" (the former is preferred, but not available
> > in the older version).
> 
> Wait; I worry that I misunderstand the use of 'default'.
> 
> Is there a thread or FM I should go read to fully understand?
> 
> That is, my understanding is that the default key is used
> so that an end user just tells his or her sound app
> to write to a 'defaults' device, and then Alsa worries
> about mapping that to the correct device.
> 
> However, in the case of Wine, my fundamental mission
> at initialization time is to provide a credible and
> useful list of sound devices back to the application,
> so the application can pick.  (At the same time, I need
> to report which of those choices is the default, and
> report that back to the application as well; I try to
> do that via the alsa config apis).

That's why I wrote above.  Just give the list of sound cards with
proper names, and let user choose the card, instead of the whole
device lists.

> But my first misunderstanding was that I thought there
> was just one default device, not one that can be
> iterated per card.  Does default:X simply get mapped
> to one of either 'hw:X' or 'plughw:X' (or whatnot) based
> on user preference?

Yes.  It's a new feature introduced since ALSA 1.0.8 (or 7?).
You can pass the card number to the "default" PCM.
Also, default:X automatically introduces the dmix for many hardwares
without multi-playback capability, while plughw doesn't.
This works unless user redefines the default in his ~/.asoundrc.

Using the word "default" is a bit tricky, I admit.
I originally wanted to name a different one, but we didn't conclude.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Jeremy White]

> Yes.  It's a new feature introduced since ALSA 1.0.8 (or 7?).
> You can pass the card number to the "default" PCM.
> Also, default:X automatically introduces the dmix for many hardwares
> without multi-playback capability, while plughw doesn't.
> This works unless user redefines the default in his ~/.asoundrc.

Okay, I think I begin to understand, although you're right, the
naming is rather unfortunate.

So it sounds like the right approach is to try default:X,
and if that fails, to fallback to plug:hw:X.

Does that sound rational?

Cheers,

Jeremy


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Takashi Iwai]

At Mon, 13 Jun 2005 10:01:03 -0500,
Jeremy White wrote:
> 
> > Yes.  It's a new feature introduced since ALSA 1.0.8 (or 7?).
> > You can pass the card number to the "default" PCM.
> > Also, default:X automatically introduces the dmix for many hardwares
> > without multi-playback capability, while plughw doesn't.
> > This works unless user redefines the default in his ~/.asoundrc.
> 
> Okay, I think I begin to understand, although you're right, the
> naming is rather unfortunate.
> 
> So it sounds like the right approach is to try default:X,
> and if that fails, to fallback to plug:hw:X.
> 
> Does that sound rational?

Yes.  That'll be good for both old and new versions.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Jeremy White]

>>So it sounds like the right approach is to try default:X,
>>and if that fails, to fallback to plug:hw:X.
>>
>>Does that sound rational?
> 
> 
> Yes.  That'll be good for both old and new versions.

Okay...next odd question.  Why does default:0
work, but default:0,0 not work?

Alsa lib 1.0.8-3 (debian), which seems like a recent
enough version to do base line testing on.

I appreciate any insight.

Thanks,

Jeremy

------
  ~/xfer/pcm -D default:0,0
Playback device is default:0,0
Stream parameters are 44100Hz, S16_LE, 1 channels
Sine wave rate is 440.0000Hz
Using transfer method: write
ALSA lib conf.c:3792:(parse_args) Unknown parameter 1
ALSA lib conf.c:3914:(snd_config_expand) Parse arguments error: No such file or directory
ALSA lib pcm.c:2068:(snd_pcm_open_noupdate) Unknown PCM default:0,0
Playback open error: No such file or directory


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

Re: RFC: Appropriate device detection for Wine (more advice needed)

[Takashi Iwai]

At Mon, 13 Jun 2005 22:22:40 -0500,
Jeremy White wrote:
> 
> >>So it sounds like the right approach is to try default:X,
> >>and if that fails, to fallback to plug:hw:X.
> >>
> >>Does that sound rational?
> > 
> > 
> > Yes.  That'll be good for both old and new versions.
> 
> Okay...next odd question.  Why does default:0
> work, but default:0,0 not work?

The default is provided only one per card.
It doesn't specify a certain devince on the card, but it's a
representive of that card.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20