ALSA plugin "device" parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 9, 2009 at 2:19 PM, Peter Nagy <nagper at gmail.com> wrote:
> Hi,
>
> Ok I see what you mean.
> But how could it happen that when I'm using native pulseaudio for
> example with gstreamer then the output goes to sound_card0 but when
> I'm using it through alsa-lib -> alsa-pulse plugin -> pulse then
> output goes to sound_card1
> If I turn off HAL detection and determine devices statically with
> module-alsa-sink then I can manage to load my preferred sound card
> first and alsa-pulse plugin will use that sound card regardless what
> is in the /etc/pulse config files
> There must be some reason of the presence of that device parameter int
> the asound.conf

The "device" parameter in the ALSA<->Pulse plugin is valid syntax;
it's also still in alsa-plugins-1.0.19 (the latest version). I'm not
sure whether the maintainers consider it of "deprecated" status or
not, as I'm just a user :) There are no comments in the source
indicating such though.

//
//Code from alsa-plugins-0.19 pulse/pcm_pulse.c line 857-879
//

if (strcmp(id, "device") == 0) {
                        if (snd_config_get_string(n, &device) < 0) {
                                SNDERR("Invalid type for %s", id);
                                return -EINVAL;
                        }
                        continue;
                }
                SNDERR("Unknown field %s", id);
                return -EINVAL;
        }

        pcm = calloc(1, sizeof(*pcm));
        if (!pcm)
                return -ENOMEM;

        if (device) {
                pcm->device = strdup(device);

                if (!pcm->device) {
                        err = -ENOMEM;
                        goto error;
                }
        }

//
//
//

As explained in the readme file:

1. The purpose of the "device" parameter is somewhat of a mis-nomer :)
2. If you are specifying the "device" parameter to an ALSA PCM (a
playback stream), it is equivalent to specifying a PulseAudio sink.
3. If you are specifying the "device" parameter to an ALSA CTL (a
capture stream), it is equivalent to specifying a PulseAudio source.

PA sinks and sources are uniquely qualified by index and by name. The
name usually doesn't (shouldn't?) change between boot-ups, whether or
not HAL initializes your device in one order or another. However, we
can't rely on the stability of sink/source indexes in PA at all.

Fortunately, we specify devices by their sink/source name in this configuration.

If you want to make a static configuration in /etc/pulse/default.pa
that will let you have stable mappings between sink names and
ALSA<->Pulse PCMs, you can do this (illustrative example, but using
this verbatim won't get you a working config):

In /etc/pulse/default.pa:
1. Comment out module-hal-detect
2. Add

load-module module-alsa-sink device=hw:0 sink_name=foo
load-module module-alsa-source device=hw:0 source_name=bar

somewhere in the file.

In /etc/asound.conf OR ~/.asoundrc:

1. Define a PCM

pcm.pulse0 {
    type pulse
    device "foo"
}

2. Define a CTL

ctl.pulse0 {
    type pulse
    device "bar"
}


Of course, if your device indexes at the *ALSA* level are not stable,
you can't really use this reliably. You might actually find that the
names PulseAudio chooses for HAL-loaded sinks are _more_ stable than
the ALSA device indices! I've had situations where, on one boot, the
internal sound card was hw:0 and USB audio was hw:1; on reboot, the
indices flipped!

This is a generic problem of "we have lots of layers that try to
index/name/uniquely qualify each device, and depending on the order of
initialization, these indices/names are not stable". It gets even
hairier if you have multiple devices of the same model number, vendor,
etc.

What you really need is for each particular instance of sound card
hardware, a stable name that is consistent across all layers -- but
this is a fundamental design problem we can't solve without some big
rework. I'm not sure of the degree to which HAL can already give us
this, if it relies on serial numbers or PCI IDs or whatever for
uniquely generating the sink/source strings.

> Or is it deprecated?
>
> Thanks
> Peter
>
>
>
> 2009/3/9 Sean McNamara <smcnam at gmail.com>:
>> Peter,
>>
>> On Mon, Mar 9, 2009 at 1:39 PM, Peter Nagy <nagper at gmail.com> wrote:
>>> Hi,
>>>
>>> I have problems setting up my asound.conf.
>>> Namely that I want to tell the alsa-pulse plugin which pulseaudio
>>> device to use (I have 2 sound cards).
>>>
>>> There is a nice short explanation in the plugin's README-pulse file:
>>>
>>> ---------------------------------
>>> "PulseAudio <--> ALSA plugins
>>> ============================
>>>
>>> This plugin allows any program that uses the ALSA API to access a PulseAudio
>>> sound daemon. In other words, native ALSA applications can play and record
>>> sound across a network.
>>>
>>> There are two plugins in the suite, one for PCM and one for mixer control. A
>>> typical configuration will look like:
>>>
>>> ? ?pcm.pulse {
>>> ? ? ? ?type pulse
>>> ? ?}
>>>
>>> ? ?ctl.pulse {
>>> ? ? ? ?type pulse
>>> ? ?}
>>>
>>> Put the above in ~/.asoundrc, or /etc/asound.conf, and use "pulse" as device
>>> in your ALSA applications. For example:
>>>
>>> ? ?% aplay -Dpulse foo.wav
>>> ? ?% amixer -Dpulse
>>>
>>> PulseAudio will accept more or less any format you throw at it. So a plug
>>> wrapper is unnecessary. Mixing is also handled so dmix will only cause a
>>> performance hit without any gain.
>>>
>>> The plugins will respect your PulseAudio environment variables (like
>>> PULSE_SERVER), but you can override these in ALSA's configuration files.
>>>
>>> Both plugins accept the "server" parameter, specifying which PulseAudio server
>>> to contact. Both also accept the "device" parameter, which indicate which
>>> source and sink to use.
>>>
>>> The mixer control plugin also accepts the parameters "source" and "sink" for
>>> when you need to specify a sink/source combination with different names. If
>>> you need to do this with PCM:s then specify two PCM:s with different "device".
>>>
>>> If you do not specify any source and/or sink, then the server's defaults will
>>> be used."
>>> ---------------------------------
>>>
>>> So what should I write in the asound.conf after the device parameter?
>>> It should be the name of the pulseaudio device what I want pulseaudio to use.
>>> It it the name of the sink? Or the alsa device name (hw:0,0)
>>> Is it a string parameter? Or string?
>>> for example:
>>>
>>> ? ?pcm.pulse {
>>> ? ? ? ?type pulse
>>> ? ? ? ?device "alsa_output.hw_0_0"
>>
>> No... Bad. PulseAudio determines which audio device to use by setting
>> up files in /etc/pulse/ (such as default.pa). You don't tell Pulse
>> which audio device to use here.
>>
>> If you have module-hal-detect loaded (any popular distro is extremely
>> likely to ship PulseAudio with this loaded and working; the default.pa
>> in the sources also turns it on by default) then PulseAudio will
>> already be aware of all of your ALSA devices, or it really should.
>>
>> You can select which device to use with `pavucontrol` at runtime.
>>
>> You don't want to have a "device" parameter to the ALSA<->pulse plugin
>> at all. None is needed in asound.conf or .asoundrc.
>>
>>
>>> ? ?}
>>>
>>> ? ?ctl.pulse {
>>> ? ? ? ?type pulse
>>> ? ? ? ?device "alsa_output.hw_0_0"
>>> ? ?}
>>>
>>> I've tried a few things with no success.
>>>
>>>
>>> Thanks for any help.
>>>
>>> Peter
>>> _______________________________________________
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss at mail.0pointer.de
>>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>>
>> _______________________________________________
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss at mail.0pointer.de
>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux