Logitech Z10 USB speakers need a volume change before audio works

Logitech Z10 USB speakers need a volume change before audio works

[Hans de Goede]

Hi,

I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.

They have this weird glitch where after turning off my PC (and their
power-supply as well) and then turning things back on, they are silent
until I change the PCM volume control for the speakers inside
alsa-mixer.

It seems like they need some "set-volume" command to be send over the
USB bus to unmute them when initially powered-up / turned on.

Is their some existing usb-audio quirk which I can try to work around this?

Regards,

Hans

Re: Logitech Z10 USB speakers need a volume change before audio works

[Takashi Iwai]

On Thu, 25 Nov 2021 12:04:41 +0100,
Hans de Goede wrote:
> 
> Hi,
> 
> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
> 
> They have this weird glitch where after turning off my PC (and their
> power-supply as well) and then turning things back on, they are silent
> until I change the PCM volume control for the speakers inside
> alsa-mixer.
> 
> It seems like they need some "set-volume" command to be send over the
> USB bus to unmute them when initially powered-up / turned on.
> 
> Is their some existing usb-audio quirk which I can try to work around this?

No such quirk is present for now.

Was it tested with 5.16-rc?  There was a change in USB-audio driver
initialization (commit b96681bd5827) and it might have some effect in
your case.

Also, it's interesting to know whether it happens also once after
suspend-resume, too.


thanks,

Takashi

Re: Logitech Z10 USB speakers need a volume change before audio works

[Hans de Goede]

Hi,

On 11/25/21 13:42, Takashi Iwai wrote:
> On Thu, 25 Nov 2021 12:04:41 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
>>
>> They have this weird glitch where after turning off my PC (and their
>> power-supply as well) and then turning things back on, they are silent
>> until I change the PCM volume control for the speakers inside
>> alsa-mixer.
>>
>> It seems like they need some "set-volume" command to be send over the
>> USB bus to unmute them when initially powered-up / turned on.
>>
>> Is their some existing usb-audio quirk which I can try to work around this?
> 
> No such quirk is present for now.
> 
> Was it tested with 5.16-rc?  There was a change in USB-audio driver
> initialization (commit b96681bd5827) and it might have some effect in
> your case.

Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
I just never got around to reporting it. Mainly because I also never
got around to getting a bit clearer picture of the problem.

I've spend some time this morning to get that clearer picture,
which was insightful.

> Also, it's interesting to know whether it happens also once after
> suspend-resume, too.

suspend-resume makes no difference, not even rebooting or
powering off the machine makes a difference.

Once the speakers are in working order they stay in working order
until I turn off my machine; and then flick the power-switch on
the 240V AC power-bar which I use to power my laptop + dock +
monitors + the speakers and turn things back on the next morning.

To be clear these speakers get their audio-data over USB
(as an usb-audio device) but they have their own power-supply
they are not USB powered. They also have a "soft" on/off button
which turns on/off the amplifier and LCD screen parts but leaves
the USB audio interface active.

So I've been experimenting with reproducing the issue and I
need to do the following minimal steps to reproduce:

 1. Unplug USB
 2. Unplug power
 3. Re-plug power
 4. Re-plug USB
 5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
 6. Turn speakers on (with the on/off button on the speakers), no audio

 5 and 6 may be swapped, same result

And now that I have a reliable reproducer I've also been
playing with a reliable workaround which looks like this:

1. Start playing audio to the speakers
2. Turn speakers on (with the on/off button on the speakers)
3. Make a change to the 'PCM Playback Volume' ctrl

Where 1. and 2. may be swapped. But the
'PCM Playback Volume' ctrl change must be made while the
speakers are on and playing audio !

Although I have found that this also works:

1. Start playing audio to the speakers
2. Turn speakers on (with the on/off button on the speakers)
3. Stop playing audio
4. Make a change to the 'PCM Playback Volume' ctrl
5. Start playing audio to the speakers again

I then even here a brief "power-up buzz" coming from the
speakers at 4.

And this sequence also works:

1. Start playing audio to the speakers
2. Stop playing audio
3. Turn speakers on (with the on/off button on the speakers)
4. Make a change to the 'PCM Playback Volume' ctrl
5. Start playing audio to the speakers again

So it seems that to work (after having been unplugged
form the mains) these speakers need to:

1. Have had some audio send to them at least once
2. After this have their 'PCM Playback Volume' ctrl poked
   at once while they are on (and if they are on cannot
   be seen from the PC side AFAICT).

Note instead of changing the 'PCM Playback Volume' ctrl
toggling the associated mute ctrl works too.

TL;DR: Since getting the speakers to work involves
setting a ctrl while they are on, which is something
which we cannot tell from the kernel side I don't believe
that there is anything we can do about this from within
the kernel.

At least we now have a detailed description of the issue
in case other users hit this too.

Regards,

Hans


p.s.

One of the reasons why I started looking into this now
is because before I could just change the volume using
volume up/down hotkeys on my kbd and that would result
in a hw volume-ctrl change fixing things. But with the
latest pipewire that workaround no longer works. So I guess
I need to talk to the pipewire devs about bringing back
the old behavior.

Re: Logitech Z10 USB speakers need a volume change before audio works

[Hans de Goede]

Hi,

On 11/30/21 12:07, Hans de Goede wrote:
> Hi,
> 
> On 11/25/21 13:42, Takashi Iwai wrote:
>> On Thu, 25 Nov 2021 12:04:41 +0100,
>> Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
>>>
>>> They have this weird glitch where after turning off my PC (and their
>>> power-supply as well) and then turning things back on, they are silent
>>> until I change the PCM volume control for the speakers inside
>>> alsa-mixer.
>>>
>>> It seems like they need some "set-volume" command to be send over the
>>> USB bus to unmute them when initially powered-up / turned on.
>>>
>>> Is their some existing usb-audio quirk which I can try to work around this?
>>
>> No such quirk is present for now.
>>
>> Was it tested with 5.16-rc?  There was a change in USB-audio driver
>> initialization (commit b96681bd5827) and it might have some effect in
>> your case.
> 
> Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
> I just never got around to reporting it. Mainly because I also never
> got around to getting a bit clearer picture of the problem.
> 
> I've spend some time this morning to get that clearer picture,
> which was insightful.
> 
>> Also, it's interesting to know whether it happens also once after
>> suspend-resume, too.
> 
> suspend-resume makes no difference, not even rebooting or
> powering off the machine makes a difference.
> 
> Once the speakers are in working order they stay in working order
> until I turn off my machine; and then flick the power-switch on
> the 240V AC power-bar which I use to power my laptop + dock +
> monitors + the speakers and turn things back on the next morning.
> 
> To be clear these speakers get their audio-data over USB
> (as an usb-audio device) but they have their own power-supply
> they are not USB powered. They also have a "soft" on/off button
> which turns on/off the amplifier and LCD screen parts but leaves
> the USB audio interface active.
> 
> So I've been experimenting with reproducing the issue and I
> need to do the following minimal steps to reproduce:
> 
>  1. Unplug USB
>  2. Unplug power
>  3. Re-plug power
>  4. Re-plug USB
>  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
>  6. Turn speakers on (with the on/off button on the speakers), no audio
> 
>  5 and 6 may be swapped, same result
> 
> And now that I have a reliable reproducer I've also been
> playing with a reliable workaround which looks like this:
> 
> 1. Start playing audio to the speakers
> 2. Turn speakers on (with the on/off button on the speakers)
> 3. Make a change to the 'PCM Playback Volume' ctrl
> 
> Where 1. and 2. may be swapped. But the
> 'PCM Playback Volume' ctrl change must be made while the
> speakers are on and playing audio !
> 
> Although I have found that this also works:
> 
> 1. Start playing audio to the speakers
> 2. Turn speakers on (with the on/off button on the speakers)
> 3. Stop playing audio
> 4. Make a change to the 'PCM Playback Volume' ctrl
> 5. Start playing audio to the speakers again
> 
> I then even here a brief "power-up buzz" coming from the
> speakers at 4.
> 
> And this sequence also works:
> 
> 1. Start playing audio to the speakers
> 2. Stop playing audio
> 3. Turn speakers on (with the on/off button on the speakers)
> 4. Make a change to the 'PCM Playback Volume' ctrl
> 5. Start playing audio to the speakers again
> 
> So it seems that to work (after having been unplugged
> form the mains) these speakers need to:
> 
> 1. Have had some audio send to them at least once
> 2. After this have their 'PCM Playback Volume' ctrl poked
>    at once while they are on (and if they are on cannot
>    be seen from the PC side AFAICT).
> 
> Note instead of changing the 'PCM Playback Volume' ctrl
> toggling the associated mute ctrl works too.
> 
> TL;DR: Since getting the speakers to work involves
> setting a ctrl while they are on, which is something
> which we cannot tell from the kernel side I don't believe
> that there is anything we can do about this from within
> the kernel.

So thinking more about this I guess we could do something
where we resend the last PCM volume to the device every
5 seconds *when the device is playing audio*, assuming that
the resending of the same PCM volume is sufficient to fix
things.

These are pretty nice speakers so getting them to work without
this glitch would be nice. But it would require a significant
bit of (quirk enabled) code just for this 1 model speakers.

Takashi, what do you think. Should I give the resend volume
once every 5 seconds idea a try, or is it likely going to
end up being too ugly to merge ?

Regards,

Hans

Re: Logitech Z10 USB speakers need a volume change before audio works

[Takashi Iwai]

On Tue, 30 Nov 2021 15:33:35 +0100,
Hans de Goede wrote:
> 
> Hi,
> 
> On 11/30/21 12:07, Hans de Goede wrote:
> > Hi,
> > 
> > On 11/25/21 13:42, Takashi Iwai wrote:
> >> On Thu, 25 Nov 2021 12:04:41 +0100,
> >> Hans de Goede wrote:
> >>>
> >>> Hi,
> >>>
> >>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
> >>>
> >>> They have this weird glitch where after turning off my PC (and their
> >>> power-supply as well) and then turning things back on, they are silent
> >>> until I change the PCM volume control for the speakers inside
> >>> alsa-mixer.
> >>>
> >>> It seems like they need some "set-volume" command to be send over the
> >>> USB bus to unmute them when initially powered-up / turned on.
> >>>
> >>> Is their some existing usb-audio quirk which I can try to work around this?
> >>
> >> No such quirk is present for now.
> >>
> >> Was it tested with 5.16-rc?  There was a change in USB-audio driver
> >> initialization (commit b96681bd5827) and it might have some effect in
> >> your case.
> > 
> > Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
> > I just never got around to reporting it. Mainly because I also never
> > got around to getting a bit clearer picture of the problem.
> > 
> > I've spend some time this morning to get that clearer picture,
> > which was insightful.
> > 
> >> Also, it's interesting to know whether it happens also once after
> >> suspend-resume, too.
> > 
> > suspend-resume makes no difference, not even rebooting or
> > powering off the machine makes a difference.
> > 
> > Once the speakers are in working order they stay in working order
> > until I turn off my machine; and then flick the power-switch on
> > the 240V AC power-bar which I use to power my laptop + dock +
> > monitors + the speakers and turn things back on the next morning.
> > 
> > To be clear these speakers get their audio-data over USB
> > (as an usb-audio device) but they have their own power-supply
> > they are not USB powered. They also have a "soft" on/off button
> > which turns on/off the amplifier and LCD screen parts but leaves
> > the USB audio interface active.
> > 
> > So I've been experimenting with reproducing the issue and I
> > need to do the following minimal steps to reproduce:
> > 
> >  1. Unplug USB
> >  2. Unplug power
> >  3. Re-plug power
> >  4. Re-plug USB
> >  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
> >  6. Turn speakers on (with the on/off button on the speakers), no audio
> > 
> >  5 and 6 may be swapped, same result
> > 
> > And now that I have a reliable reproducer I've also been
> > playing with a reliable workaround which looks like this:
> > 
> > 1. Start playing audio to the speakers
> > 2. Turn speakers on (with the on/off button on the speakers)
> > 3. Make a change to the 'PCM Playback Volume' ctrl
> > 
> > Where 1. and 2. may be swapped. But the
> > 'PCM Playback Volume' ctrl change must be made while the
> > speakers are on and playing audio !
> > 
> > Although I have found that this also works:
> > 
> > 1. Start playing audio to the speakers
> > 2. Turn speakers on (with the on/off button on the speakers)
> > 3. Stop playing audio
> > 4. Make a change to the 'PCM Playback Volume' ctrl
> > 5. Start playing audio to the speakers again
> > 
> > I then even here a brief "power-up buzz" coming from the
> > speakers at 4.
> > 
> > And this sequence also works:
> > 
> > 1. Start playing audio to the speakers
> > 2. Stop playing audio
> > 3. Turn speakers on (with the on/off button on the speakers)
> > 4. Make a change to the 'PCM Playback Volume' ctrl
> > 5. Start playing audio to the speakers again
> > 
> > So it seems that to work (after having been unplugged
> > form the mains) these speakers need to:
> > 
> > 1. Have had some audio send to them at least once
> > 2. After this have their 'PCM Playback Volume' ctrl poked
> >    at once while they are on (and if they are on cannot
> >    be seen from the PC side AFAICT).
> > 
> > Note instead of changing the 'PCM Playback Volume' ctrl
> > toggling the associated mute ctrl works too.
> > 
> > TL;DR: Since getting the speakers to work involves
> > setting a ctrl while they are on, which is something
> > which we cannot tell from the kernel side I don't believe
> > that there is anything we can do about this from within
> > the kernel.
> 
> So thinking more about this I guess we could do something
> where we resend the last PCM volume to the device every
> 5 seconds *when the device is playing audio*, assuming that
> the resending of the same PCM volume is sufficient to fix
> things.
> 
> These are pretty nice speakers so getting them to work without
> this glitch would be nice. But it would require a significant
> bit of (quirk enabled) code just for this 1 model speakers.
> 
> Takashi, what do you think. Should I give the resend volume
> once every 5 seconds idea a try, or is it likely going to
> end up being too ugly to merge ?

It sounds too hackish and fragile to me...  Do we need to repeat each
5 seconds?  Wouldn't it suffice to touch only once at setting up the
stream (or need before or after the stream start), instead?

If it's enough to be once in the stream setup, we may add something in
snd_usb_set_format_quirk() that is specific to your device to set the
current mixer value again.

In anyway, alsa-info.sh output would be helpful.


thanks,

Takashi

Re: Logitech Z10 USB speakers need a volume change before audio works

[Hans de Goede]

Hi,

On 11/30/21 16:56, Takashi Iwai wrote:
> On Tue, 30 Nov 2021 15:33:35 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> On 11/30/21 12:07, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 11/25/21 13:42, Takashi Iwai wrote:
>>>> On Thu, 25 Nov 2021 12:04:41 +0100,
>>>> Hans de Goede wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
>>>>>
>>>>> They have this weird glitch where after turning off my PC (and their
>>>>> power-supply as well) and then turning things back on, they are silent
>>>>> until I change the PCM volume control for the speakers inside
>>>>> alsa-mixer.
>>>>>
>>>>> It seems like they need some "set-volume" command to be send over the
>>>>> USB bus to unmute them when initially powered-up / turned on.
>>>>>
>>>>> Is their some existing usb-audio quirk which I can try to work around this?
>>>>
>>>> No such quirk is present for now.
>>>>
>>>> Was it tested with 5.16-rc?  There was a change in USB-audio driver
>>>> initialization (commit b96681bd5827) and it might have some effect in
>>>> your case.
>>>
>>> Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
>>> I just never got around to reporting it. Mainly because I also never
>>> got around to getting a bit clearer picture of the problem.
>>>
>>> I've spend some time this morning to get that clearer picture,
>>> which was insightful.
>>>
>>>> Also, it's interesting to know whether it happens also once after
>>>> suspend-resume, too.
>>>
>>> suspend-resume makes no difference, not even rebooting or
>>> powering off the machine makes a difference.
>>>
>>> Once the speakers are in working order they stay in working order
>>> until I turn off my machine; and then flick the power-switch on
>>> the 240V AC power-bar which I use to power my laptop + dock +
>>> monitors + the speakers and turn things back on the next morning.
>>>
>>> To be clear these speakers get their audio-data over USB
>>> (as an usb-audio device) but they have their own power-supply
>>> they are not USB powered. They also have a "soft" on/off button
>>> which turns on/off the amplifier and LCD screen parts but leaves
>>> the USB audio interface active.
>>>
>>> So I've been experimenting with reproducing the issue and I
>>> need to do the following minimal steps to reproduce:
>>>
>>>  1. Unplug USB
>>>  2. Unplug power
>>>  3. Re-plug power
>>>  4. Re-plug USB
>>>  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
>>>  6. Turn speakers on (with the on/off button on the speakers), no audio
>>>
>>>  5 and 6 may be swapped, same result
>>>
>>> And now that I have a reliable reproducer I've also been
>>> playing with a reliable workaround which looks like this:
>>>
>>> 1. Start playing audio to the speakers
>>> 2. Turn speakers on (with the on/off button on the speakers)
>>> 3. Make a change to the 'PCM Playback Volume' ctrl
>>>
>>> Where 1. and 2. may be swapped. But the
>>> 'PCM Playback Volume' ctrl change must be made while the
>>> speakers are on and playing audio !
>>>
>>> Although I have found that this also works:
>>>
>>> 1. Start playing audio to the speakers
>>> 2. Turn speakers on (with the on/off button on the speakers)
>>> 3. Stop playing audio
>>> 4. Make a change to the 'PCM Playback Volume' ctrl
>>> 5. Start playing audio to the speakers again
>>>
>>> I then even here a brief "power-up buzz" coming from the
>>> speakers at 4.
>>>
>>> And this sequence also works:
>>>
>>> 1. Start playing audio to the speakers
>>> 2. Stop playing audio
>>> 3. Turn speakers on (with the on/off button on the speakers)
>>> 4. Make a change to the 'PCM Playback Volume' ctrl
>>> 5. Start playing audio to the speakers again
>>>
>>> So it seems that to work (after having been unplugged
>>> form the mains) these speakers need to:
>>>
>>> 1. Have had some audio send to them at least once
>>> 2. After this have their 'PCM Playback Volume' ctrl poked
>>>    at once while they are on (and if they are on cannot
>>>    be seen from the PC side AFAICT).
>>>
>>> Note instead of changing the 'PCM Playback Volume' ctrl
>>> toggling the associated mute ctrl works too.
>>>
>>> TL;DR: Since getting the speakers to work involves
>>> setting a ctrl while they are on, which is something
>>> which we cannot tell from the kernel side I don't believe
>>> that there is anything we can do about this from within
>>> the kernel.
>>
>> So thinking more about this I guess we could do something
>> where we resend the last PCM volume to the device every
>> 5 seconds *when the device is playing audio*, assuming that
>> the resending of the same PCM volume is sufficient to fix
>> things.
>>
>> These are pretty nice speakers so getting them to work without
>> this glitch would be nice. But it would require a significant
>> bit of (quirk enabled) code just for this 1 model speakers.
>>
>> Takashi, what do you think. Should I give the resend volume
>> once every 5 seconds idea a try, or is it likely going to
>> end up being too ugly to merge ?
> 
> It sounds too hackish and fragile to me...

Yes, I agree,

> Do we need to repeat each
> 5 seconds?  Wouldn't it suffice to touch only once at setting up the
> stream (or need before or after the stream start), instead?

The problem is that at least with my testing with alsamixer + speaker-test
I need to make the PCM ctl change when the speakers are on.

And I often find myself doing the following:

1. Start something which requires working audio
2. Oh wait, the speakers are off, turn them on

At which point if we do this at stream-start this would require
a pause + unpause. At which point just hitting volume up + down
hotkeys is just as easy (easier even when in say a video-conf-call).

So I believe my time is better spend to track down the pipewire
regression where newer pipewire versions no longer use hw-volume-ctrl
on these speakers for some reason. Fixing that will restore my old
workaround and will hopefully also help other users.

I guess this is mostly an issue for me because I turn of the
mains power to the speakers every evening, other users just
need to fiddle with the volume once and then things will work
until the speakers get unplugged from the mains.

> In anyway, alsa-info.sh output would be helpful.

Sure here you go:
http://alsa-project.org/db/?f=8b93e72b6fb4be5c426eade5f78ed58137bdf0ef'

Note there are quite a few audio devices in my setup:

1. My X1 carbon laptop's builtin sound
2. The Thunderbolt docks' USB audio (unused)
3. A TI USB audio codec going to the receiver connected to
my proper/real speakers for listening music
4. The Logitech Z-10 speakers which we are discussing here

Anyway, not sure if this is worth spending much (more) time on
but if you have some idea for me to test, let me know.

Regards,

Hans

Re: Logitech Z10 USB speakers need a volume change before audio works

[Takashi Iwai]

On Wed, 01 Dec 2021 16:44:11 +0100,
Hans de Goede wrote:
> 
> Hi,
> 
> On 11/30/21 16:56, Takashi Iwai wrote:
> > On Tue, 30 Nov 2021 15:33:35 +0100,
> > Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 11/30/21 12:07, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 11/25/21 13:42, Takashi Iwai wrote:
> >>>> On Thu, 25 Nov 2021 12:04:41 +0100,
> >>>> Hans de Goede wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
> >>>>>
> >>>>> They have this weird glitch where after turning off my PC (and their
> >>>>> power-supply as well) and then turning things back on, they are silent
> >>>>> until I change the PCM volume control for the speakers inside
> >>>>> alsa-mixer.
> >>>>>
> >>>>> It seems like they need some "set-volume" command to be send over the
> >>>>> USB bus to unmute them when initially powered-up / turned on.
> >>>>>
> >>>>> Is their some existing usb-audio quirk which I can try to work around this?
> >>>>
> >>>> No such quirk is present for now.
> >>>>
> >>>> Was it tested with 5.16-rc?  There was a change in USB-audio driver
> >>>> initialization (commit b96681bd5827) and it might have some effect in
> >>>> your case.
> >>>
> >>> Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
> >>> I just never got around to reporting it. Mainly because I also never
> >>> got around to getting a bit clearer picture of the problem.
> >>>
> >>> I've spend some time this morning to get that clearer picture,
> >>> which was insightful.
> >>>
> >>>> Also, it's interesting to know whether it happens also once after
> >>>> suspend-resume, too.
> >>>
> >>> suspend-resume makes no difference, not even rebooting or
> >>> powering off the machine makes a difference.
> >>>
> >>> Once the speakers are in working order they stay in working order
> >>> until I turn off my machine; and then flick the power-switch on
> >>> the 240V AC power-bar which I use to power my laptop + dock +
> >>> monitors + the speakers and turn things back on the next morning.
> >>>
> >>> To be clear these speakers get their audio-data over USB
> >>> (as an usb-audio device) but they have their own power-supply
> >>> they are not USB powered. They also have a "soft" on/off button
> >>> which turns on/off the amplifier and LCD screen parts but leaves
> >>> the USB audio interface active.
> >>>
> >>> So I've been experimenting with reproducing the issue and I
> >>> need to do the following minimal steps to reproduce:
> >>>
> >>>  1. Unplug USB
> >>>  2. Unplug power
> >>>  3. Re-plug power
> >>>  4. Re-plug USB
> >>>  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
> >>>  6. Turn speakers on (with the on/off button on the speakers), no audio
> >>>
> >>>  5 and 6 may be swapped, same result
> >>>
> >>> And now that I have a reliable reproducer I've also been
> >>> playing with a reliable workaround which looks like this:
> >>>
> >>> 1. Start playing audio to the speakers
> >>> 2. Turn speakers on (with the on/off button on the speakers)
> >>> 3. Make a change to the 'PCM Playback Volume' ctrl
> >>>
> >>> Where 1. and 2. may be swapped. But the
> >>> 'PCM Playback Volume' ctrl change must be made while the
> >>> speakers are on and playing audio !
> >>>
> >>> Although I have found that this also works:
> >>>
> >>> 1. Start playing audio to the speakers
> >>> 2. Turn speakers on (with the on/off button on the speakers)
> >>> 3. Stop playing audio
> >>> 4. Make a change to the 'PCM Playback Volume' ctrl
> >>> 5. Start playing audio to the speakers again
> >>>
> >>> I then even here a brief "power-up buzz" coming from the
> >>> speakers at 4.
> >>>
> >>> And this sequence also works:
> >>>
> >>> 1. Start playing audio to the speakers
> >>> 2. Stop playing audio
> >>> 3. Turn speakers on (with the on/off button on the speakers)
> >>> 4. Make a change to the 'PCM Playback Volume' ctrl
> >>> 5. Start playing audio to the speakers again
> >>>
> >>> So it seems that to work (after having been unplugged
> >>> form the mains) these speakers need to:
> >>>
> >>> 1. Have had some audio send to them at least once
> >>> 2. After this have their 'PCM Playback Volume' ctrl poked
> >>>    at once while they are on (and if they are on cannot
> >>>    be seen from the PC side AFAICT).
> >>>
> >>> Note instead of changing the 'PCM Playback Volume' ctrl
> >>> toggling the associated mute ctrl works too.
> >>>
> >>> TL;DR: Since getting the speakers to work involves
> >>> setting a ctrl while they are on, which is something
> >>> which we cannot tell from the kernel side I don't believe
> >>> that there is anything we can do about this from within
> >>> the kernel.
> >>
> >> So thinking more about this I guess we could do something
> >> where we resend the last PCM volume to the device every
> >> 5 seconds *when the device is playing audio*, assuming that
> >> the resending of the same PCM volume is sufficient to fix
> >> things.
> >>
> >> These are pretty nice speakers so getting them to work without
> >> this glitch would be nice. But it would require a significant
> >> bit of (quirk enabled) code just for this 1 model speakers.
> >>
> >> Takashi, what do you think. Should I give the resend volume
> >> once every 5 seconds idea a try, or is it likely going to
> >> end up being too ugly to merge ?
> > 
> > It sounds too hackish and fragile to me...
> 
> Yes, I agree,
> 
> > Do we need to repeat each
> > 5 seconds?  Wouldn't it suffice to touch only once at setting up the
> > stream (or need before or after the stream start), instead?
> 
> The problem is that at least with my testing with alsamixer + speaker-test
> I need to make the PCM ctl change when the speakers are on.
> 
> And I often find myself doing the following:
> 
> 1. Start something which requires working audio
> 2. Oh wait, the speakers are off, turn them on
> 
> At which point if we do this at stream-start this would require
> a pause + unpause. At which point just hitting volume up + down
> hotkeys is just as easy (easier even when in say a video-conf-call).
> 
> So I believe my time is better spend to track down the pipewire
> regression where newer pipewire versions no longer use hw-volume-ctrl
> on these speakers for some reason. Fixing that will restore my old
> workaround and will hopefully also help other users.
> 
> I guess this is mostly an issue for me because I turn of the
> mains power to the speakers every evening, other users just
> need to fiddle with the volume once and then things will work
> until the speakers get unplugged from the mains.
> 
> > In anyway, alsa-info.sh output would be helpful.
> 
> Sure here you go:
> http://alsa-project.org/db/?f=8b93e72b6fb4be5c426eade5f78ed58137bdf0ef'
> 
> Note there are quite a few audio devices in my setup:
> 
> 1. My X1 carbon laptop's builtin sound
> 2. The Thunderbolt docks' USB audio (unused)
> 3. A TI USB audio codec going to the receiver connected to
> my proper/real speakers for listening music
> 4. The Logitech Z-10 speakers which we are discussing here
> 
> Anyway, not sure if this is worth spending much (more) time on
> but if you have some idea for me to test, let me know.

Below is a quick hack, let's see whether this kind of change is
enough for this device.


Takashi

--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1280,6 +1280,15 @@ int snd_usb_apply_interface_quirk(struct snd_usb_audio *chip,
 				  int iface,
 				  int altno)
 {
+#ifdef CONFIG_PM
+	if (chip->usb_id == USB_ID(0x046d, 0x0a07)) {
+		struct usb_mixer_interface *mixer;
+		list_for_each_entry(mixer, &chip->mixer_list, list)
+			snd_usb_mixer_resume(mixer);
+		return 0;
+	}
+#endif
+
 	/* audiophile usb: skip altsets incompatible with device_setup */
 	if (chip->usb_id == USB_ID(0x0763, 0x2003))
 		return audiophile_skip_setting_quirk(chip, iface, altno);

Re: Logitech Z10 USB speakers need a volume change before audio works

[Hans de Goede]

Hi Takashi,

On 12/2/21 09:25, Takashi Iwai wrote:
> On Wed, 01 Dec 2021 16:44:11 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> On 11/30/21 16:56, Takashi Iwai wrote:
>>> On Tue, 30 Nov 2021 15:33:35 +0100,
>>> Hans de Goede wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 11/30/21 12:07, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 11/25/21 13:42, Takashi Iwai wrote:
>>>>>> On Thu, 25 Nov 2021 12:04:41 +0100,
>>>>>> Hans de Goede wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
>>>>>>>
>>>>>>> They have this weird glitch where after turning off my PC (and their
>>>>>>> power-supply as well) and then turning things back on, they are silent
>>>>>>> until I change the PCM volume control for the speakers inside
>>>>>>> alsa-mixer.
>>>>>>>
>>>>>>> It seems like they need some "set-volume" command to be send over the
>>>>>>> USB bus to unmute them when initially powered-up / turned on.
>>>>>>>
>>>>>>> Is their some existing usb-audio quirk which I can try to work around this?
>>>>>>
>>>>>> No such quirk is present for now.
>>>>>>
>>>>>> Was it tested with 5.16-rc?  There was a change in USB-audio driver
>>>>>> initialization (commit b96681bd5827) and it might have some effect in
>>>>>> your case.
>>>>>
>>>>> Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
>>>>> I just never got around to reporting it. Mainly because I also never
>>>>> got around to getting a bit clearer picture of the problem.
>>>>>
>>>>> I've spend some time this morning to get that clearer picture,
>>>>> which was insightful.
>>>>>
>>>>>> Also, it's interesting to know whether it happens also once after
>>>>>> suspend-resume, too.
>>>>>
>>>>> suspend-resume makes no difference, not even rebooting or
>>>>> powering off the machine makes a difference.
>>>>>
>>>>> Once the speakers are in working order they stay in working order
>>>>> until I turn off my machine; and then flick the power-switch on
>>>>> the 240V AC power-bar which I use to power my laptop + dock +
>>>>> monitors + the speakers and turn things back on the next morning.
>>>>>
>>>>> To be clear these speakers get their audio-data over USB
>>>>> (as an usb-audio device) but they have their own power-supply
>>>>> they are not USB powered. They also have a "soft" on/off button
>>>>> which turns on/off the amplifier and LCD screen parts but leaves
>>>>> the USB audio interface active.
>>>>>
>>>>> So I've been experimenting with reproducing the issue and I
>>>>> need to do the following minimal steps to reproduce:
>>>>>
>>>>>  1. Unplug USB
>>>>>  2. Unplug power
>>>>>  3. Re-plug power
>>>>>  4. Re-plug USB
>>>>>  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
>>>>>  6. Turn speakers on (with the on/off button on the speakers), no audio
>>>>>
>>>>>  5 and 6 may be swapped, same result
>>>>>
>>>>> And now that I have a reliable reproducer I've also been
>>>>> playing with a reliable workaround which looks like this:
>>>>>
>>>>> 1. Start playing audio to the speakers
>>>>> 2. Turn speakers on (with the on/off button on the speakers)
>>>>> 3. Make a change to the 'PCM Playback Volume' ctrl
>>>>>
>>>>> Where 1. and 2. may be swapped. But the
>>>>> 'PCM Playback Volume' ctrl change must be made while the
>>>>> speakers are on and playing audio !
>>>>>
>>>>> Although I have found that this also works:
>>>>>
>>>>> 1. Start playing audio to the speakers
>>>>> 2. Turn speakers on (with the on/off button on the speakers)
>>>>> 3. Stop playing audio
>>>>> 4. Make a change to the 'PCM Playback Volume' ctrl
>>>>> 5. Start playing audio to the speakers again
>>>>>
>>>>> I then even here a brief "power-up buzz" coming from the
>>>>> speakers at 4.
>>>>>
>>>>> And this sequence also works:
>>>>>
>>>>> 1. Start playing audio to the speakers
>>>>> 2. Stop playing audio
>>>>> 3. Turn speakers on (with the on/off button on the speakers)
>>>>> 4. Make a change to the 'PCM Playback Volume' ctrl
>>>>> 5. Start playing audio to the speakers again
>>>>>
>>>>> So it seems that to work (after having been unplugged
>>>>> form the mains) these speakers need to:
>>>>>
>>>>> 1. Have had some audio send to them at least once
>>>>> 2. After this have their 'PCM Playback Volume' ctrl poked
>>>>>    at once while they are on (and if they are on cannot
>>>>>    be seen from the PC side AFAICT).
>>>>>
>>>>> Note instead of changing the 'PCM Playback Volume' ctrl
>>>>> toggling the associated mute ctrl works too.
>>>>>
>>>>> TL;DR: Since getting the speakers to work involves
>>>>> setting a ctrl while they are on, which is something
>>>>> which we cannot tell from the kernel side I don't believe
>>>>> that there is anything we can do about this from within
>>>>> the kernel.
>>>>
>>>> So thinking more about this I guess we could do something
>>>> where we resend the last PCM volume to the device every
>>>> 5 seconds *when the device is playing audio*, assuming that
>>>> the resending of the same PCM volume is sufficient to fix
>>>> things.
>>>>
>>>> These are pretty nice speakers so getting them to work without
>>>> this glitch would be nice. But it would require a significant
>>>> bit of (quirk enabled) code just for this 1 model speakers.
>>>>
>>>> Takashi, what do you think. Should I give the resend volume
>>>> once every 5 seconds idea a try, or is it likely going to
>>>> end up being too ugly to merge ?
>>>
>>> It sounds too hackish and fragile to me...
>>
>> Yes, I agree,
>>
>>> Do we need to repeat each
>>> 5 seconds?  Wouldn't it suffice to touch only once at setting up the
>>> stream (or need before or after the stream start), instead?
>>
>> The problem is that at least with my testing with alsamixer + speaker-test
>> I need to make the PCM ctl change when the speakers are on.
>>
>> And I often find myself doing the following:
>>
>> 1. Start something which requires working audio
>> 2. Oh wait, the speakers are off, turn them on
>>
>> At which point if we do this at stream-start this would require
>> a pause + unpause. At which point just hitting volume up + down
>> hotkeys is just as easy (easier even when in say a video-conf-call).
>>
>> So I believe my time is better spend to track down the pipewire
>> regression where newer pipewire versions no longer use hw-volume-ctrl
>> on these speakers for some reason. Fixing that will restore my old
>> workaround and will hopefully also help other users.
>>
>> I guess this is mostly an issue for me because I turn of the
>> mains power to the speakers every evening, other users just
>> need to fiddle with the volume once and then things will work
>> until the speakers get unplugged from the mains.
>>
>>> In anyway, alsa-info.sh output would be helpful.
>>
>> Sure here you go:
>> http://alsa-project.org/db/?f=8b93e72b6fb4be5c426eade5f78ed58137bdf0ef'
>>
>> Note there are quite a few audio devices in my setup:
>>
>> 1. My X1 carbon laptop's builtin sound
>> 2. The Thunderbolt docks' USB audio (unused)
>> 3. A TI USB audio codec going to the receiver connected to
>> my proper/real speakers for listening music
>> 4. The Logitech Z-10 speakers which we are discussing here
>>
>> Anyway, not sure if this is worth spending much (more) time on
>> but if you have some idea for me to test, let me know.
> 
> Below is a quick hack, let's see whether this kind of change is
> enough for this device.
> 
> 
> Takashi
> 
> --- a/sound/usb/quirks.c
> +++ b/sound/usb/quirks.c
> @@ -1280,6 +1280,15 @@ int snd_usb_apply_interface_quirk(struct snd_usb_audio *chip,
>  				  int iface,
>  				  int altno)
>  {
> +#ifdef CONFIG_PM
> +	if (chip->usb_id == USB_ID(0x046d, 0x0a07)) {
> +		struct usb_mixer_interface *mixer;
> +		list_for_each_entry(mixer, &chip->mixer_list, list)
> +			snd_usb_mixer_resume(mixer);
> +		return 0;
> +	}
> +#endif
> +
>  	/* audiophile usb: skip altsets incompatible with device_setup */
>  	if (chip->usb_id == USB_ID(0x0763, 0x2003))
>  		return audiophile_skip_setting_quirk(chip, iface, altno);
> 

Thanks, unfortunately this does not make any difference.

Regards,

Hans

Re: Logitech Z10 USB speakers need a volume change before audio works

[Takashi Iwai]

On Mon, 06 Dec 2021 14:54:08 +0100,
Hans de Goede wrote:
> 
> Hi Takashi,
> 
> On 12/2/21 09:25, Takashi Iwai wrote:
> > On Wed, 01 Dec 2021 16:44:11 +0100,
> > Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 11/30/21 16:56, Takashi Iwai wrote:
> >>> On Tue, 30 Nov 2021 15:33:35 +0100,
> >>> Hans de Goede wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 11/30/21 12:07, Hans de Goede wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 11/25/21 13:42, Takashi Iwai wrote:
> >>>>>> On Thu, 25 Nov 2021 12:04:41 +0100,
> >>>>>> Hans de Goede wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I've a set of Logitech Z10 USB speakers, which act as a USB soundcard.
> >>>>>>>
> >>>>>>> They have this weird glitch where after turning off my PC (and their
> >>>>>>> power-supply as well) and then turning things back on, they are silent
> >>>>>>> until I change the PCM volume control for the speakers inside
> >>>>>>> alsa-mixer.
> >>>>>>>
> >>>>>>> It seems like they need some "set-volume" command to be send over the
> >>>>>>> USB bus to unmute them when initially powered-up / turned on.
> >>>>>>>
> >>>>>>> Is their some existing usb-audio quirk which I can try to work around this?
> >>>>>>
> >>>>>> No such quirk is present for now.
> >>>>>>
> >>>>>> Was it tested with 5.16-rc?  There was a change in USB-audio driver
> >>>>>> initialization (commit b96681bd5827) and it might have some effect in
> >>>>>> your case.
> >>>>>
> >>>>> Yes I'm at 5.16-rc3 atm but I've been seeing this for quite some time.
> >>>>> I just never got around to reporting it. Mainly because I also never
> >>>>> got around to getting a bit clearer picture of the problem.
> >>>>>
> >>>>> I've spend some time this morning to get that clearer picture,
> >>>>> which was insightful.
> >>>>>
> >>>>>> Also, it's interesting to know whether it happens also once after
> >>>>>> suspend-resume, too.
> >>>>>
> >>>>> suspend-resume makes no difference, not even rebooting or
> >>>>> powering off the machine makes a difference.
> >>>>>
> >>>>> Once the speakers are in working order they stay in working order
> >>>>> until I turn off my machine; and then flick the power-switch on
> >>>>> the 240V AC power-bar which I use to power my laptop + dock +
> >>>>> monitors + the speakers and turn things back on the next morning.
> >>>>>
> >>>>> To be clear these speakers get their audio-data over USB
> >>>>> (as an usb-audio device) but they have their own power-supply
> >>>>> they are not USB powered. They also have a "soft" on/off button
> >>>>> which turns on/off the amplifier and LCD screen parts but leaves
> >>>>> the USB audio interface active.
> >>>>>
> >>>>> So I've been experimenting with reproducing the issue and I
> >>>>> need to do the following minimal steps to reproduce:
> >>>>>
> >>>>>  1. Unplug USB
> >>>>>  2. Unplug power
> >>>>>  3. Re-plug power
> >>>>>  4. Re-plug USB
> >>>>>  5. speaker-test -Dfront:CARD=Speaker,DEV=0 -S1
> >>>>>  6. Turn speakers on (with the on/off button on the speakers), no audio
> >>>>>
> >>>>>  5 and 6 may be swapped, same result
> >>>>>
> >>>>> And now that I have a reliable reproducer I've also been
> >>>>> playing with a reliable workaround which looks like this:
> >>>>>
> >>>>> 1. Start playing audio to the speakers
> >>>>> 2. Turn speakers on (with the on/off button on the speakers)
> >>>>> 3. Make a change to the 'PCM Playback Volume' ctrl
> >>>>>
> >>>>> Where 1. and 2. may be swapped. But the
> >>>>> 'PCM Playback Volume' ctrl change must be made while the
> >>>>> speakers are on and playing audio !
> >>>>>
> >>>>> Although I have found that this also works:
> >>>>>
> >>>>> 1. Start playing audio to the speakers
> >>>>> 2. Turn speakers on (with the on/off button on the speakers)
> >>>>> 3. Stop playing audio
> >>>>> 4. Make a change to the 'PCM Playback Volume' ctrl
> >>>>> 5. Start playing audio to the speakers again
> >>>>>
> >>>>> I then even here a brief "power-up buzz" coming from the
> >>>>> speakers at 4.
> >>>>>
> >>>>> And this sequence also works:
> >>>>>
> >>>>> 1. Start playing audio to the speakers
> >>>>> 2. Stop playing audio
> >>>>> 3. Turn speakers on (with the on/off button on the speakers)
> >>>>> 4. Make a change to the 'PCM Playback Volume' ctrl
> >>>>> 5. Start playing audio to the speakers again
> >>>>>
> >>>>> So it seems that to work (after having been unplugged
> >>>>> form the mains) these speakers need to:
> >>>>>
> >>>>> 1. Have had some audio send to them at least once
> >>>>> 2. After this have their 'PCM Playback Volume' ctrl poked
> >>>>>    at once while they are on (and if they are on cannot
> >>>>>    be seen from the PC side AFAICT).
> >>>>>
> >>>>> Note instead of changing the 'PCM Playback Volume' ctrl
> >>>>> toggling the associated mute ctrl works too.
> >>>>>
> >>>>> TL;DR: Since getting the speakers to work involves
> >>>>> setting a ctrl while they are on, which is something
> >>>>> which we cannot tell from the kernel side I don't believe
> >>>>> that there is anything we can do about this from within
> >>>>> the kernel.
> >>>>
> >>>> So thinking more about this I guess we could do something
> >>>> where we resend the last PCM volume to the device every
> >>>> 5 seconds *when the device is playing audio*, assuming that
> >>>> the resending of the same PCM volume is sufficient to fix
> >>>> things.
> >>>>
> >>>> These are pretty nice speakers so getting them to work without
> >>>> this glitch would be nice. But it would require a significant
> >>>> bit of (quirk enabled) code just for this 1 model speakers.
> >>>>
> >>>> Takashi, what do you think. Should I give the resend volume
> >>>> once every 5 seconds idea a try, or is it likely going to
> >>>> end up being too ugly to merge ?
> >>>
> >>> It sounds too hackish and fragile to me...
> >>
> >> Yes, I agree,
> >>
> >>> Do we need to repeat each
> >>> 5 seconds?  Wouldn't it suffice to touch only once at setting up the
> >>> stream (or need before or after the stream start), instead?
> >>
> >> The problem is that at least with my testing with alsamixer + speaker-test
> >> I need to make the PCM ctl change when the speakers are on.
> >>
> >> And I often find myself doing the following:
> >>
> >> 1. Start something which requires working audio
> >> 2. Oh wait, the speakers are off, turn them on
> >>
> >> At which point if we do this at stream-start this would require
> >> a pause + unpause. At which point just hitting volume up + down
> >> hotkeys is just as easy (easier even when in say a video-conf-call).
> >>
> >> So I believe my time is better spend to track down the pipewire
> >> regression where newer pipewire versions no longer use hw-volume-ctrl
> >> on these speakers for some reason. Fixing that will restore my old
> >> workaround and will hopefully also help other users.
> >>
> >> I guess this is mostly an issue for me because I turn of the
> >> mains power to the speakers every evening, other users just
> >> need to fiddle with the volume once and then things will work
> >> until the speakers get unplugged from the mains.
> >>
> >>> In anyway, alsa-info.sh output would be helpful.
> >>
> >> Sure here you go:
> >> http://alsa-project.org/db/?f=8b93e72b6fb4be5c426eade5f78ed58137bdf0ef'
> >>
> >> Note there are quite a few audio devices in my setup:
> >>
> >> 1. My X1 carbon laptop's builtin sound
> >> 2. The Thunderbolt docks' USB audio (unused)
> >> 3. A TI USB audio codec going to the receiver connected to
> >> my proper/real speakers for listening music
> >> 4. The Logitech Z-10 speakers which we are discussing here
> >>
> >> Anyway, not sure if this is worth spending much (more) time on
> >> but if you have some idea for me to test, let me know.
> > 
> > Below is a quick hack, let's see whether this kind of change is
> > enough for this device.
> > 
> > 
> > Takashi
> > 
> > --- a/sound/usb/quirks.c
> > +++ b/sound/usb/quirks.c
> > @@ -1280,6 +1280,15 @@ int snd_usb_apply_interface_quirk(struct snd_usb_audio *chip,
> >  				  int iface,
> >  				  int altno)
> >  {
> > +#ifdef CONFIG_PM
> > +	if (chip->usb_id == USB_ID(0x046d, 0x0a07)) {
> > +		struct usb_mixer_interface *mixer;
> > +		list_for_each_entry(mixer, &chip->mixer_list, list)
> > +			snd_usb_mixer_resume(mixer);
> > +		return 0;
> > +	}
> > +#endif
> > +
> >  	/* audiophile usb: skip altsets incompatible with device_setup */
> >  	if (chip->usb_id == USB_ID(0x0763, 0x2003))
> >  		return audiophile_skip_setting_quirk(chip, iface, altno);
> > 
> 
> Thanks, unfortunately this does not make any difference.

OK, then it's not that straightforward :-<


Takashi