All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Logitech Z10 USB speakers need a volume change before audio works
Date: Tue, 30 Nov 2021 12:07:04 +0100	[thread overview]
Message-ID: <c1deb0b9-b0f1-3ea5-43ea-ac96b29e93f5@redhat.com> (raw)
In-Reply-To: <s5ho8689zl3.wl-tiwai@suse.de>

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.


  reply	other threads:[~2021-11-30 11:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-25 11:04 Logitech Z10 USB speakers need a volume change before audio works Hans de Goede
2021-11-25 12:42 ` Takashi Iwai
2021-11-30 11:07   ` Hans de Goede [this message]
2021-11-30 14:33     ` Hans de Goede
2021-11-30 15:56       ` Takashi Iwai
2021-12-01 15:44         ` Hans de Goede
2021-12-02  8:25           ` Takashi Iwai
2021-12-06 13:54             ` Hans de Goede
2021-12-07  8:07               ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1deb0b9-b0f1-3ea5-43ea-ac96b29e93f5@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.