https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287813
Bug ID: 287813
Summary: USB headset not properly initialized
Product: Base System
Version: 14.3-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: usb
Assignee: usb@FreeBSD.org
Reporter: f...@opal.com
I have a snd_uaudio dongle that provides USB-to-Bluetooth support. I am using
it with a Bluetooth headset.
To be clear, this is a USB device that attaches using the snd_uaudio driver.
The Bluetooth side of things is not visible to FreeBSD: it is not using the ubt
driver.
The device has USB ids:
idVendor = 0x0b0e
idProduct = 0x24c8
and appears to be a GN Netcom dongle also used by Jabra (although mine came
with the headset and does not have any vendor details on it). Full USB details
at [1].
The device is not being properly initialized. When first connected to a USB
port, the dongle LED lights and the headset announces "Connected".
However, when playing audio, the most you get is a few seconds then it stops,
stutters and soon appears to reset - at which point the LED on the dongle goes
out and the headset announces "Disconnected". After a short while, the LED
lights again and the headset announces "Connected" again.
My normal usage is using the oss driver only - no sndio or pulseaudio. I am
testing using "mplayer file.mp3" and also using firefox (YouTube, Meet, Zoom,
etc).
Firefox is configured to use oss only: media.cubeb.backend=oss
I have tried playing with the various parameters in hw.usb.uaudio.* but nothing
makes much difference:
hw.usb.uaudio.buffer_ms 2 gives a slight improvement
hw.usb.uaudio.default_bits 16 gives a slight improvement
hw.usb.uaudio.default_rate doesn't seem to make any difference
While fiddling around, I did install pulseaudio, but it also did not help...
until I ran "pactl exit" to stop the daemon. AFTER that, the device works
perfectly!! I can then play multiple files using mplayer (with the oss driver)
without errors. I can also have Meet, Zoom, etc calls in firefox without
problems but I notice that when firefox closes the audio channel, once again
there is a device reset (with the headset announcing
"Disconnected"/"Connected") and it then gets into a loop, continuously
resetting. Another "pactl exit" fixes it again.
On investigating "pactl", if the pulseaudio daemon is not running, it is always
started even if the command is "exit". So, "pactl exit" is starting the
pulseaudio daemon which is somehow causing snd_uaudio or device parameters to
be altered such that this dongle is happy. After which, the pulseaudio daemon
exits, but the parameter settings remain and now audio via the oss driver works
okay.
I've discussed in PM with Christos Margiolis and we feel that this is more of a
USB problem than an audio problem, since the device does work perfectly after
being opened by the pulseaudio daemon. My presumption is that the pulseaudio
daemon is setting some device USB parameter(s) to match the driver and we need
to figure out what and do the same initialization in the driver itself.
We also discovered that the patch at [5] (now committed) makes things worse!
With that patch, there is no audio at all, even after running the "pactl exit"
hack. I am having to run on a kernel with that patch reverted.
I have provided [1] USB device details, [2] a truss trace of the "pactl exit"
run, [3] the pulseaudio verbose log and [4] a USB dump of the dialog when
"pactl exit" is run at the links below.
[1] usbconfig dump_device_desc
https://opal.com/~jr/btv5.2/usbconfig.txt
[2] truss trace of "pactl exit" as the pulseaudio daemon opens the device
(scroll to line 2965 to see the /dev/dsp2 open)
https://opal.com/~jr/btv5.2/truss_pactl_exit.txt
[3] verbose log from pulseaudio
https://opal.com/~jr/btv5.2/pulse-debug.txt
[4] USB dialog during pulseaudio run
https://opal.com/~jr/btv5.2/usbdump-v.txt
[5] D50488 needs to be reverted for it to work at all
https://reviews.freebsd.org/D50488
--
You are receiving this mail because:
You are the assignee for the bug.
