Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
Dne 23. 02. 20 v 10:00 Tanu Kaskinen napsal(a):
On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote:
On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote:
Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a):
On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote:
+ pulseaudio-discuss@lists.freedesktop.org
On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote:
Actually, I am also trying to resolve the description of the speaker
configuration. It may not be only enough to give the PCM device, because we
don't know, if user connected the stereo or surround speakers to the sound
card output for example. I play with an idea to add device variants to UCM,
but the question is, how we can map this to pulseaudio profile/port schematics.
My quick idea is to export those variants via the verbs, so the exported verb
names might look like:
HiFi:Speaker-Stereo
HiFi:Speaker-5.1
Where 'HiFi' is the verb name, 'Speaker' is the device name and 'Stereo' is
the variant name.
If we need to define multiple variants, all may be exported like:
HiFi:Speaker-5.1,Mic-4.0
Also, we can enhance this and store the configuration to a file, thus 'HiFi'
can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default.
Verb + list-of-device-variants sounds like a good way to map UCM
devices to pulseaudio profiles (and if there's just one verb, which I
expect to be the common case, don't show it in the profile name). I
don't know how the variants should be configured in UCM, but I know
that device variants should be able to declare conflicts with other
devices (or device variants). For example, 5.1 speaker output may make
recording impossible, while stereo speaker output can be used toghether
with a mic. If this information is not provided by UCM, pulseaudio will
have to probe all variant combinations (like it currently does with the
legacy mixer system).
Sorry, now I realized that the Verb + list-of-device-variants scheme
doesn't really work after all as the profile scheme. Or maybe it does,
but it's significantly different from what we do currently. Switching
between Headphones and Speaker-Stereo often doesn't require reopening
the PCM device, so there's no need for separate Headphones and Speaker-
Stereo profiles. I guess we could still create separate profiles, it
just means that the profile list will get much longer.
We could add a separate optimization step to the profile creation
process. That is, first create all possible device-variant combinations
as the initial profile list, and then inspect which profiles can be
merged. Naming the merged profiles becomes a problem, but I imagine
it's solvable with static rules (e.g. merging Speakers-Stereo and
Headphones becomes Analog-Stereo), and if necessary the merging can be
improved gradually over time.
From profile creation perspective the ideal scheme would be not based
on UCM devices but on PCM devices and their configuration variants, but
I imagine naming would be an even bigger problem with this scheme (how
to map PCM device names to sensible user friendly names?).
I think that I didn't explain my idea in detail. The variant verbs may be
almost identical (thus all devices will be defined) like the "master" one. But
the specific variant configuration will be returned to the application. So it
will differ only in the channel count value for the Speaker device or so. The
PCM device name + PCM parameters check will be fine. I don't think that we
should modify something on the PA side. PA activates only one verb per
soundcard now.
Oh, you want to create variant verbs? Is the idea that all possible
device combinations will be made separate verbs? That would make life
easier for PulseAudio, but wouldn't it mean a lot more work for UCM
configuration writers? Rather than generating the device combinations
automatically in PulseAudio, the combinations would have to be manually
listed in every UCM configuration.
I think it would be better to define only one verb per sound card and
declare the conflicts between the devices or device variants, and let
PulseAudio automatically generate the device combinations as profiles.
I may be misunderstanding something, I didn't for example understand
what you meant by "the PCM device name + PCM parameters check will be
fine". Some examples could be useful. Let's say that there's a sound
card that has stereo output (either headphones or line-out), 4.0
output, 5.1 output, SPDIF output and stereo input. If input is used,
5.1 output can't be used at the same time. Would UCM define the
following verbs?:
HiFi:Headphones,SPDIF,Mic
HiFi:Line-Stereo,SPDIF,Mic
HiFi:Line-4.0,SPDIF,Mic
HiFi:Line-5.1,SPDIF
I'm currently writing UCM configuration for Audigy2, because
PulseAudio's default configuration doesn't work with that card
properly. I'm creating verbs for each possible device combination, and
Note that variants are not supported in UCM yet. I expect to add the
VariantSection to the DeviceSection like this:
SectionDevice."Speaker" {
[pulseaudio-discuss] Latency problem with module-loopback after downtime
Hi,
No, this is not about the usual loopback latency ;) I have found a
strange anomaly.
I have 2 sound cards: C-Media CMI8738 (I've check, well supported on
Linux, work great)
1st is for Toslink input, 2nd for Toslink output (and this is the
default and only sink for the whole system)
I'm setting up a loopback device like this:
pactl load-module module-loopback \
latency_msec=1 \
source=alsa_input.pci-_06_01.0.iec958-stereo \
sink=alsa_output.pci-_06_02.0.iec958-stereo
And this works great! Latency is very low:
Sink Input #0
Driver: module-loopback.c
[...]
Buffer Latency: 10250 usec
Sink Latency: 7263 usec
Source Output #0
Driver: module-loopback.c
[...]
Buffer Latency: 0 usec
Source Latency: 380 usec
Now, here is the problem. When I unplug a cable of the source, source
latency rises to infinity. And I understand why, it's fine, but, when I
plug the cable again, then: source Latency slowly goes down, but sink's
buffer latency rises, up to even 8-12 seconds.
Notes:
- Reloading the module is a fix.
- by unplug I mean unplug, or shut down the source: anything that
stops the signal.
What I'm looking for:
1. This is most likely a bug, which I could help analyze by providing
more data.
2. But in the meantime, I'm looking for a way to reload the module when
source device shows up. This is the best I came up with so far, in tmux:
watch -n 105 'pactl list | grep -A 12 module-loopback.c | grep "Source
Latency" | grep -Eo "[0-9]{9}" &> /dev/null && pactl unload-module
module-loopback && sleep 6 && pactl load-module module-loopback
latency_msec=1 source=alsa_input.pci-_06_01.0.iec958-stereo
sink=alsa_output.pci-_06_02.0.iec958-stereo && echo "reload"'
(if Source Latency goes over 8 digit number (100seconds), reload the
module-loopback)
--
dextkrk
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [alsa-devel] Question about the various mixer options in UCM
On Sat, 2020-02-22 at 08:53 +0200, Tanu Kaskinen wrote: > On Sun, 2020-02-16 at 18:38 +0100, Jaroslav Kysela wrote: > > Dne 16. 02. 20 v 11:06 Tanu Kaskinen napsal(a): > > > On Sun, 2020-02-16 at 11:42 +0200, Tanu Kaskinen wrote: > > > > + pulseaudio-discuss@lists.freedesktop.org > > > > > > > > On Sat, 2020-02-15 at 17:25 +0100, Jaroslav Kysela wrote: > > > > > Actually, I am also trying to resolve the description of the speaker > > > > > configuration. It may not be only enough to give the PCM device, > > > > > because we > > > > > don't know, if user connected the stereo or surround speakers to the > > > > > sound > > > > > card output for example. I play with an idea to add device variants > > > > > to UCM, > > > > > but the question is, how we can map this to pulseaudio profile/port > > > > > schematics. > > > > > > > > > > My quick idea is to export those variants via the verbs, so the > > > > > exported verb > > > > > names might look like: > > > > > > > > > > HiFi:Speaker-Stereo > > > > > HiFi:Speaker-5.1 > > > > > > > > > > Where 'HiFi' is the verb name, 'Speaker' is the device name and > > > > > 'Stereo' is > > > > > the variant name. > > > > > > > > > > If we need to define multiple variants, all may be exported like: > > > > > > > > > > HiFi:Speaker-5.1,Mic-4.0 > > > > > > > > > > Also, we can enhance this and store the configuration to a file, thus > > > > > 'HiFi' > > > > > can refer to 'HiFi@Speaker-5.1,Mic-4.0' by default. > > > > > > > > Verb + list-of-device-variants sounds like a good way to map UCM > > > > devices to pulseaudio profiles (and if there's just one verb, which I > > > > expect to be the common case, don't show it in the profile name). I > > > > don't know how the variants should be configured in UCM, but I know > > > > that device variants should be able to declare conflicts with other > > > > devices (or device variants). For example, 5.1 speaker output may make > > > > recording impossible, while stereo speaker output can be used toghether > > > > with a mic. If this information is not provided by UCM, pulseaudio will > > > > have to probe all variant combinations (like it currently does with the > > > > legacy mixer system). > > > > > > Sorry, now I realized that the Verb + list-of-device-variants scheme > > > doesn't really work after all as the profile scheme. Or maybe it does, > > > but it's significantly different from what we do currently. Switching > > > between Headphones and Speaker-Stereo often doesn't require reopening > > > the PCM device, so there's no need for separate Headphones and Speaker- > > > Stereo profiles. I guess we could still create separate profiles, it > > > just means that the profile list will get much longer. > > > > > > We could add a separate optimization step to the profile creation > > > process. That is, first create all possible device-variant combinations > > > as the initial profile list, and then inspect which profiles can be > > > merged. Naming the merged profiles becomes a problem, but I imagine > > > it's solvable with static rules (e.g. merging Speakers-Stereo and > > > Headphones becomes Analog-Stereo), and if necessary the merging can be > > > improved gradually over time. > > > > > > > From profile creation perspective the ideal scheme would be not based > > > on UCM devices but on PCM devices and their configuration variants, but > > > I imagine naming would be an even bigger problem with this scheme (how > > > to map PCM device names to sensible user friendly names?). > > > > I think that I didn't explain my idea in detail. The variant verbs may be > > almost identical (thus all devices will be defined) like the "master" one. > > But > > the specific variant configuration will be returned to the application. So > > it > > will differ only in the channel count value for the Speaker device or so. > > The > > PCM device name + PCM parameters check will be fine. I don't think that we > > should modify something on the PA side. PA activates only one verb per > > soundcard now. > > Oh, you want to create variant verbs? Is the idea that all possible > device combinations will be made separate verbs? That would make life > easier for PulseAudio, but wouldn't it mean a lot more work for UCM > configuration writers? Rather than generating the device combinations > automatically in PulseAudio, the combinations would have to be manually > listed in every UCM configuration. > > I think it would be better to define only one verb per sound card and > declare the conflicts between the devices or device variants, and let > PulseAudio automatically generate the device combinations as profiles. > > I may be misunderstanding something, I didn't for example understand > what you meant by "the PCM device name + PCM parameters check will be > fine". Some examples could be useful. Let's say that there's a sound > card that has stereo output (either headphones or line-out), 4.0 > output, 5.1 output, SPDIF output and
