I've tried exactly what you sad but device parameter is not working for me.
Anyway changing the module load order gives a workaround
Thanks for your help.
Peter
2009/3/9 Sean McNamara <smcnam at gmail.com>:
> 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
>>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
