Bug 99607

Another strange behavior: if I change the sound volume using the keyboard media key, the sound revert to the pulseaudio volume configuration for about a second, but jump back to 100% after. In case it's not clear enough, an example:

 - the USB DAC is at 100% volume, the current stream at something low like 20%. The stream volume has no effect, the DAC volume is at the max;

 - I lower the volume using the keyboard media: this controls the USB DAC and it shows going from 100% to 95% (this value doesn't seem to matter). Immediately the DAC volume matches subjectively the 20% pulse volume;

 - After a short duration, about 1 second, the volume jump back to maximum.

This behavior is independent of the USB DAC volume setting. The only thing affecting the volume is the playing stream setting, for a short second.
So it seems that the volume can be properly set, but something overrides it.
Any pointers on things to check to fix this welcomed...

If the card presents a volume element that doesn't do anything, that's a kernel driver bug, and should be reported to the alsa developers:
http://alsa-project.org/main/index.php/Bug_Tracking

There's currently no simple way to disable hardware volume. One way to do it is to set the card profile to "off" and then load module-alsa-sink. When you set the card profile to "off", the module-alsa-card instance that was loaded automatically by module-udev-detect will not try to use the device, so it won't conflict with the module-alsa-sink instance that you load manually. module-alsa-sink doesn't use hardware volume unless you explicitly tell it to.

Here's the command to set the profile to "off" (you can also do this with pavucontrol):

pactl set-card-profile alsa_card.usb-Burr-Brown_from_TI_USB_Audio_DAC-00 off

Here's the command to load module-alsa-sink:

pactl load-module module-alsa-sink device=hw:2

("hw:2" assumes that the alsa card index is 2.)

The set-card-profile command needs to be given only once. The load-module command needs to be given every time you boot or plug in the sound card. If the sound card is always plugged in, you can put the load-module command in /etc/pulse/default.pa.

Btw, attachments are nicer for big dumps of information, because if they're in the message body, reading the bug discussion requires a lot of scrolling.

If you put "flat-volumes = no" to ~/.pulse/config/daemon.conf, I think the stream volume should have the expected effect. I don't know why the volume jumps temporarily to a low level in your experiment, but with flat volumes enabled the stream volume is mostly implemented in hardware, which doesn't work with your sound card.

Hi Tanu,

Thanks for your time and advice. What you recommended in #comment 2 worked perfectly, and solved both issues I noticed. Disabling the card and re-enabling it manually without relying on auto-detection indeed gets the software volume working immediately. I can also see the SPDIF/iec958 output explicitly listed for the USB DAC, as before the regression.

Please excuse a maybe naive question (I've only superficial knowledge of the Linux audio stack): if it's possible to get the card properly set-up, wouldn't this be an auto-detection issue rather than a driver one? Unless the driver somehow drives/influence in a bad way the auto-detection process?

Thanks again,

Jerome

(In reply to Jerome from comment #4)
> if it's possible to get the card properly set-up,
> wouldn't this be an auto-detection issue rather than a driver one? Unless
> the driver somehow drives/influence in a bad way the auto-detection process?

The driver claims that the sound card provides hardware volume control, but actually it doesn't. Should PulseAudio ignore all hardware volume controls, because on some cards they do nothing? Surely not. There's no way PulseAudio can automatically figure out whether a hardware volume control does something or not, other than by having a list of hardware with broken drivers. Rather than working around broken drivers in PulseAudio, the drivers should be fixed.

Sure, this policy makes sense. After digging more, the issue is mostly on the hardware side. There may be a way to be more user friendly however, TBC.

There are two levels of oddities for the hardware, at the device architecture and USB levels. The device architecture is:

          ----------------------              -------------
  USB --->| PCM2706 Burr Brown |-- IEC958 --->| Sabre DAC |---> Analog out
          ----------------------              -------------     Headset
                    |
                    V
                Analog out
                 UNUSED!

The PCM2706 is only used for its USB interface. It has an internal DAC with an analog output, but this output is not used. Instead, the PCM2706 has a digital output, which is used to feed another better DAC from Sabre. This other DAC output is the device output (headset 3.5 mm jack).

But at the USB level, only the PCM2706 is seen with a completely stock configuration. Even the USB id is generic for the PCM2706, so there's no way to identify this specific set-up.

And the USB audio class descriptors of the PCM2706 do not even reflect its internal set-up. It would have been possible to describe at the USB level both analog and digital output, but that's not done. From the USB descriptors, the PCM2706 is a simple pipe with just the analog output:

   --------------------     ---------------     -----------------
   | USB input stream |---->| Mute+Volume |---->| Analog output |
   --------------------     ---------------     -----------------

There is indeed hardware volume support, but from the PCM2706 datasheet it applies only to the (unused) analog output, not to the digital IEC958 interface.

I saw two changes when upgrading from Jessie to Stretch:
  1) selecting the analog profile used to give no sound, now it does
     with a step volume effect;
  2) the IEC95 profile had disappeared.

The first change (1) I now understand: it's just that the IEC958 output is enabled too when the analog output is enabled. The driver level correctly report a hardware volume control for the analog output. But it doesn't apply to the actually used IEC958 output (per the PCM2706 datasheet). And when the volume is set to 0, the mute is likely enabled and this does apply to the IEC958 output too. So the observed behavior is OK. Enabling the IEC958 output too confused me, but why not.
(I still don't understand why using the keyboard volume control switches to software volume for a split second before going back to hardware, but it's a minor point)

The second change (2) was the real problem in my case. But after the suggested work-around the IEC958 profile is back, and when using it all is ok again. I set it as default profile, and it's sticky across reboots / plug and unplug now. I didn't see it disappear again since.

Because the IEC958 output is not part of the USB description, this profile must be added by a driver handling the PCM2706. I tried to grep around for the Burr Brown id and this device family (270[4567]) in the kernel source and ALSA data, but couldn't find where it is managed. The datasheet is not clear either on how the digital output is controlled. So I don't understand how this interface is handled and why it disappeared.

Anyway, considering the situation and with the IEC958 profile back, both pulseaudio and the driver level both reflect the reality of the device hardware.

The only improvement (maybe?) could be to prefer the IEC958 profile to the analog output of the PCM2706, if this digital port is connected. From what I see the PCM2706 is now mostly used for its USB interface, and the HifimeDIY type of design is common. There are other better cheap DAC for the analog ouput, and even a cheap USB DAC dongle like the HifimeDIY can afford one. This would avoid the strange experience with the default analog output (higher priority for now). 
However this would require reliably detecting that the PCM2706 digital output is used, to avoid a regression for old PCM2706 only device using its built-in DAC and where the IEC958 output is not used. I don't know if this is possible.
Even if it's not, this comment can at least help clarify what's happening for users of this USB DAC or similar designs ;)

Thanks

Sorry for slow reply, I have trouble keeping up with the pace of incoming emails...

(In reply to Jerome from comment #6)
> Sure, this policy makes sense. After digging more, the issue is mostly on
> the hardware side. There may be a way to be more user friendly however, TBC.
> 
> There are two levels of oddities for the hardware, at the device
> architecture and USB levels. The device architecture is:
> 
>           ----------------------              -------------
>   USB --->| PCM2706 Burr Brown |-- IEC958 --->| Sabre DAC |---> Analog out
>           ----------------------              -------------     Headset
>                     |
>                     V
>                 Analog out
>                  UNUSED!
> 
> The PCM2706 is only used for its USB interface. It has an internal DAC with
> an analog output, but this output is not used. Instead, the PCM2706 has a
> digital output, which is used to feed another better DAC from Sabre. This
> other DAC output is the device output (headset 3.5 mm jack).
> 
> But at the USB level, only the PCM2706 is seen with a completely stock
> configuration. Even the USB id is generic for the PCM2706, so there's no way
> to identify this specific set-up.
> 
> And the USB audio class descriptors of the PCM2706 do not even reflect its
> internal set-up. It would have been possible to describe at the USB level
> both analog and digital output, but that's not done. From the USB
> descriptors, the PCM2706 is a simple pipe with just the analog output:
> 
>    --------------------     ---------------     -----------------
>    | USB input stream |---->| Mute+Volume |---->| Analog output |
>    --------------------     ---------------     -----------------
> 
> There is indeed hardware volume support, but from the PCM2706 datasheet it
> applies only to the (unused) analog output, not to the digital IEC958
> interface.
> 
> I saw two changes when upgrading from Jessie to Stretch:
>   1) selecting the analog profile used to give no sound, now it does
>      with a step volume effect;
>   2) the IEC95 profile had disappeared.
> 
> The first change (1) I now understand: it's just that the IEC958 output is
> enabled too when the analog output is enabled. The driver level correctly
> report a hardware volume control for the analog output. But it doesn't apply
> to the actually used IEC958 output (per the PCM2706 datasheet). And when the
> volume is set to 0, the mute is likely enabled and this does apply to the
> IEC958 output too. So the observed behavior is OK. Enabling the IEC958
> output too confused me, but why not.

What does "aplay -l" print? Your description sounds like on Jessie there were separate alsa PCM devices for analog and digital (likely "hw:x,0" for analog and "hw:x,1" for digital, with the latter mapped to "iec958:x"), but now there's only digital, which pulseaudio incorrectly guesses is analog (for analog stereo output, pulseaudio tries first "front:x" and if that doesn't work, pulseaudio tries "hw:x,0" and if that works, pulseaudio assumes that it's an analog device even if it isn't).

> (I still don't understand why using the keyboard volume control switches to
> software volume for a split second before going back to hardware, but it's a
> minor point)
> 
> The second change (2) was the real problem in my case. But after the
> suggested work-around the IEC958 profile is back, and when using it all is
> ok again. I set it as default profile, and it's sticky across reboots / plug
> and unplug now. I didn't see it disappear again since.

Which work-around are you referring to? Setting the card profile to "off" and loading module-alsa-sink? If that's the workaround, what does "the IEC958 profile is back" mean? If you load module-alsa-sink, that shouldn't have any effect on the set of available profiles on the card object.

> Because the IEC958 output is not part of the USB description, this profile
> must be added by a driver handling the PCM2706. I tried to grep around for
> the Burr Brown id and this device family (270[4567]) in the kernel source
> and ALSA data, but couldn't find where it is managed. The datasheet is not
> clear either on how the digital output is controlled. So I don't understand
> how this interface is handled and why it disappeared.

I don't know all the details either, but since pulseaudio doesn't any more present a digital profile on the card, the "iec958" PCM device has apparently been removed for the card in the alsa configuration (shipped in alsa-lib). To verify, you can check the output of "aplay -L" - does it show that a device named iec958 exists?

Created attachment 130906 [details]
Output of alsa-info.sh during the missing DAC IEC958 output issue

(In reply to Tanu Kaskinen from comment #7)
> Sorry for slow reply, I have trouble keeping up with the pace of incoming
> emails...

It's ok, and thanks a lot for your time. I cannot reproduce the issue anymore, the IEC958 interface is now always there and working fine. If you want me to check some things I'd be happy to help, but otherwise I don't think you should spend time on this. It looks like a transient glitch at a time when Stretch was still moving quite fast.

Besides this glitch, a change that could make sense IMHO is to set the IEC958 interface of a PCM2706 chip (when seen ;) at a higher priority than it's analog output: it seems today the PCM2706 is mostly used for its USB interface only and not as a DAC. The D/A conversion is done by a better DAC chip, as for my dongle:

[...] The device architecture is:
> > 
> >           ----------------------              -------------
> >   USB --->| PCM2706 Burr Brown |-- IEC958 --->| Sabre DAC |---> Analog out
> >           ----------------------              -------------     Headset
> >                     |
> >                     V
> >                 Analog out
> >                  UNUSED!

When I plugged the dongle on a Win7 PC, audio worked out of the box with a fixed level so Win7 did use the IEC958 port by default. So it looks like a safe choice. And for now PA gives higher priority to the analog output, as shown by "pacmd list-cards":

 profiles:
    output:analog-mono: Analog Mono Output (priority 200, available: unknown)
    output:analog-stereo: Analog Stereo Output (priority 6000, available: unknown)
    output:iec958-stereo: Digital Stereo (IEC958) Output (priority 5500, available: unknown)
    off: Off (priority 0, available: unknown)

So a user plugging this DAC will not have any sound until manually selecting the IEC958 output. Having the IEC958 as highest priority would give sound out of the box. Do you think it's worth creating a bug entry for this? If yes would it be for PA, or are the priority set elsewhere?

I reply to your questions below, but again feel free to skip.

> What does "aplay -l" print? Your description sounds like on Jessie there
> were separate alsa PCM devices for analog and digital (likely "hw:x,0" for
> analog and "hw:x,1" for digital, with the latter mapped to "iec958:x"), but
> now there's only digital, which pulseaudio incorrectly guesses is analog
> (for analog stereo output, pulseaudio tries first "front:x" and if that
> doesn't work, pulseaudio tries "hw:x,0" and if that works, pulseaudio
> assumes that it's an analog device even if it isn't).

I can't reproduce the issue, but see the output of alsa-info.sh in comment #7.

Now on stretch with things back ok, "aplay -l" gives only one entry for the USB DAC:

 card 2: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
   Subdevices: 1/1
   Subdevice #0: subdevice #0

> > The second change (2) was the real problem in my case. But after the
> > suggested work-around the IEC958 profile is back, and when using it all is
> > ok again. I set it as default profile, and it's sticky across reboots / plug
> > and unplug now. I didn't see it disappear again since.
> 
> Which work-around are you referring to? Setting the card profile to "off"
> and loading module-alsa-sink?

Yes, doing as in comment #2.

> If that's the workaround, what does "the IEC958 profile is back" mean?

The "IEC958 profile is back" means I can see it at pulseaudio level. When doing a "pactl list cards" the entry for the USB DAC "Profiles" section is now:

 Profiles:
    output:analog-mono: Analog Mono Output (sinks: 1, sources: 0, priority: 200, available: yes)
    output:analog-stereo: Analog Stereo Output (sinks: 1, sources: 0, priority: 6000, available: yes)
    output:iec958-stereo: Digital Stereo (IEC958) Output (sinks: 1, sources: 0, priority: 5500, available: yes)
    off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
 Active Profile: output:iec958-stereo

So the IEC958 profile is properly listed again.

Before, when I had the issue, the IEC958 profile was missing at PA level. Only the analog mono, stereo and off profiles were shown. When I tried to force select a (not shown) iec958-stereo profile from the CLI, it was rejected as an error. So only the analog output was usable, and the IEC958 was gone and not shown in any PA UI (CLI or GUI).

> If you load module-alsa-sink, that shouldn't
> have any effect on the set of available profiles on the card object.

Stretch was quite a moving target at the time, I can't rule out that something else changed that got the IEC958 back. But subjectively, I ran the 2 commands and noticed the IEC958 being back again. And it's been fine since then.

> > Because the IEC958 output is not part of the USB description, this profile
> > must be added by a driver handling the PCM2706. I tried to grep around for
> > the Burr Brown id and this device family (270[4567]) in the kernel source
> > and ALSA data, but couldn't find where it is managed. The datasheet is not
> > clear either on how the digital output is controlled. So I don't understand
> > how this interface is handled and why it disappeared.
> 
> I don't know all the details either, but since pulseaudio doesn't any more
> present a digital profile on the card, the "iec958" PCM device has
> apparently been removed for the card in the alsa configuration (shipped in
> alsa-lib). To verify, you can check the output of "aplay -L" - does it show
> that a device named iec958 exists?

I can't reproduce the issue now, but I do have the output of alsa-info.sh from when the USB DAC IEC958 was gone. It does not show any iec958 interface for the USB DAC, so ALSA wasn't seeing it (attached as comment #7).

Now things are back to normal "aplay -L" does show an IEC958 entry for the DAC:

  iec958:CARD=DAC,DEV=0
  USB Audio DAC, USB Audio
  IEC958 (S/PDIF) Digital Audio Output

So it looks like it was a transient ALSA level detection issue. 

Thanks again.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/463.