Behringer UMC404 USB2 audio interface disconnects when initialized

Bug #1402196 reported by Thomas Meyssonnier
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Medium
Unassigned

Bug Description

My audio interface, a Behriger UMC404, disappears from both lsusb and /proc/asound/cards as soon as I start jackd (JACK 2). This results in jackd failing because the card is missing. It reports a "protocol error" which I think refers to the USB link. See attached syslog messages. The card does not show up at all in Pulseaudio. Also, this card works just fine on my desktop, the bug only occurs on my laptop.

Thanks,
TM

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-lowlatency 3.13.0.43.50
ProcVersionSignature: Ubuntu 3.13.0-43.72-lowlatency 3.13.11.11
Uname: Linux 3.13.0-43-lowlatency x86_64
ApportVersion: 2.14.1-0ubuntu3.6
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: tmeysson 3178 F.... pulseaudio
 /dev/snd/controlC0: tmeysson 3178 F.... pulseaudio
CurrentDesktop: XFCE
Date: Sat Dec 13 14:39:46 2014
HibernationDevice: RESUME=UUID=be114ffc-be9c-47e3-b2b6-7f49c90f9931
InstallationDate: Installed on 2014-12-03 (10 days ago)
InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.1)
MachineType: Hewlett-Packard HP EliteBook 840 G1
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-43-lowlatency root=UUID=20e973d8-558f-476d-9979-54c79133177e ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-43-lowlatency N/A
 linux-backports-modules-3.13.0-43-lowlatency N/A
 linux-firmware 1.127.10
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/03/2014
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: L71 Ver. 01.21
dmi.board.name: 198F
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 15.55
dmi.chassis.asset.tag: 5CG446445Q
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvrL71Ver.01.21:bd09/03/2014:svnHewlett-Packard:pnHPEliteBook840G1:pvrA3008CD10003:rvnHewlett-Packard:rn198F:rvrKBCVersion15.55:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: HP EliteBook 840 G1
dmi.product.version: A3008CD10003
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
Thomas Meyssonnier (thomas-meyssonnier) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Thomas Meyssonnier (thomas-meyssonnier) wrote :

Further testing reveals the interface works with playback only at 44.1kHz, 1024 frames, 3 periods.
However there are continual clicks when playing audio, while jackd does not report xruns.
Jackd does start at 48 or 96 kHz, or with 128 frames/period, but then there is no sound (but no errors either). Or sometimes sound justs stops at some point, but jackd is still running without errors or xruns.
Best possible performance (with clicks) is 44.1kHz, 256 frames/period, 3 periods/buffer.
Still the interface is reported as running at high speed.
On the other (desktop) PC there is no such issue, as I reported before (works flawlessly at 96kHz with 2ms latency).

Revision history for this message
Thomas Meyssonnier (thomas-meyssonnier) wrote :

Also, in the above test case the interface has to be unplugged and re-plugged when jackd is stopped and restarted, otherwise another error occurs.

I also tried with another (USB1.1) interface and there is no such problem.

Revision history for this message
penalvch (penalvch) wrote :

Thomas Meyssonnier, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available from the very top line at the top of the page (the release names are irrelevant for testing, and please do not test the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.

If the test did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested exactly shown as:
kernel-fixed-upstream-3.18

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

tags: added: latest-bios-1.21
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
tags: added: kernel-bug-exists-upstream-3.18
removed: amd64 apport-bug latest-bios-1.21 trusty
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Thomas Meyssonnier (thomas-meyssonnier) wrote :

Kernel 3.18 fixes the bug only for playback-only or capture-only mode, with rates up to 96kHz (the maximum) and latency down to 2ms. Duplex modes still have a great number of xruns (every 5-10s), even with very conservative settings (44.1kHz, 1024 frames/period, 3 periods/buffer), and mostly the same at higher speeds. This makes the interface impossible to use in duplex. Maybe this isn't the same bug though ?

penalvch (penalvch)
tags: added: amd64 apport-bug latest-bios-1.21 trusty
Revision history for this message
penalvch (penalvch) wrote :

Thomas Meyssonnier, given that it went from not working at all, to it's working in a non-preferred way, it would seem helpful to identify this commit (and in turn the committer) in order to advise them on how it's improved but may need more work by them. Hence, the next step is to fully reverse commit bisect from kernel 3.13 to 3.18 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ? Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Thomas Meyssonnier (thomas-meyssonnier) wrote :

Okay, I found the bug goes less severe as soon as kernel 3.13.2, which is to say I bisected kernels from 3.18.0 down only to find this was mostly fixed a long time since. The bug for duplex is more severe in older versions, causing jackd to crash in 3.13.2 while 3.18.0 only has continuous xruns. That tells me they're actually working on it continuously since then; it is actually a major issue for linux audio since it's about having proper usb interfaces for laptops. I've seen quite a lot of work about that from someone called Clemens Ladisch.
So I might track down the exact commit that solved it for one-way communication, but I guess the person working on that knows all about it... pretty useless then.

Best regards,
TM

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.