Issue with alsa virtual multi channel device

[GDO]

I have heard this kind of argument/warning before (from phoman). Honestly I have not seen device order swapping on my hardware (Raspberry Pi 2) EVER. I believe that this is because the USB ports have a fixed index in the bus and as long as you keep the same DACs plugged into the same USB ports, they will always be referenced in the same order as the ports.

So, Mr Chicken Little, the sky isn't falling!

Cross fingers?😡

 

[CharlieLaub]

Cross fingers?😡

What, upset that someone might disagree with you - someone (me) who has actually done this for an extended period of time and NOT experienced any problems... 😱

If you are so convinced this is a problem, run a repeated test for this behavior and prove to everyone that you are in the right. I think you will find that your fears are completely unsupported if you obtain some real world evidence using the following procedure:

• Do not unplug the devices from the USB port.
• Cycle the power.
• Check the hw assignment of the devices in ALSA after bootup.
• Repeat.

One could probably create a script to do that, assuming you can ID each device through the OS by a serial number, etc. as you mentioned before.

 

[GDO]

• Do not unplug the devices from the USB port.
• Cycle the power.
• Check the hw assignment of the devices in ALSA after bootup.
• Repeat.

One could probably create a script to do that, assuming you can ID each device through the OS by a serial number, etc. as you mentioned before.

Nothing less?😀

I agree udev rules are also a real pain to set up, but a least when it's done it's fool proof and the only thing you have to worry about is plug the right usb device into its assigned usb plug.

 

[JMF11]

Hi and YESSS !!!!!

Phofman found the issue 🙂 problem of USB bandwith with my 2 amps on the same USB bus.

This is was a (or the) cause associated with the alsa error message:
Unable to set hw params for playback: Broken pipe
Setting of hwparams failed: Broken pipe

Or the error code:
aplay: set_params:1297: Unable to install hw params:

dmesg reported:
cannot submit urb 0, error -28: not enough bandwidth

It was possible to play to each amp individually. But when I tried to play on both of them from 2 different terms, then the first was starting well, but I had a broken pipe for the second.

ecasound splitting was failing also with broken pipe...

Changing the USB plug for one of the amps solved the issue.

My virtual multichannel device works with speaker-test -Dmulti, I can play sound with 2 terms sending sound to amps in parallel, ecasound does not have anymore a broken pipe.

Still things to test and adjust, but this is solved 🙂

Thank you a lot for your help, I would not have found alone

Best regards,

JMF

 

[phofman]

Perfect, congrats. I wonder what speed your USB port features. 4 channels 44/16 is way below capacity of the 12mbps bus. Perhaps only USB 1.0 - 1.5Mbps?

Hopefully the two busses are clocked by the same PPL to stay in sync. Probably yes.

 

[CharlieLaub]

Changing the USB plug for one of the amps solved the issue.

I'm glad that you were able to get it working!

Can you clarify what the problem was exactly and what you mean by the above statement? Was there a problem with the USB cable? OR do you mean you changed how a "device plug" was defined in an ALSA configuration file?

What sample rate and bit depth can you use?

 

[GDO]

Well, what about upgrading that computer to an Rpi?🙄

 

[JMF11]

@phofman: I agree with you, this USB bandwith issue is surprising. The laptop I use is not so old and well designed: a 2007 R61 Thinkpad with core duo T7100 and 3xUSB 2.0

@CharlieLaub: there are 3 USB 2.0 on my laptop. 2 one above the other on the right side of the laptop, and 1 on the right side. Initially, I had my 2 amps connected to the 2xUSB on the same side. To solve my issue, I have now one amp connected on the left side, and one amp on the right side. I have no information about the internal architecture of the R61, to define if there is only one USB host or more...

@GDO: I received last monday an Orange Pi PC. I should have bought a RPi for quality, reliability of distributions and community support, but could not resist to try the cheap thing. I powered it up yesterday with the dedicated Openelec distribution, and have in mind to build on top of that a MPD server + ecasound + LADSPA ACD... A good thing is that there are no USB bottlenecks on those boards.

I'm surprised that the board gets hot inside its plastic box (standard orange pi box), even at idle (I would say box wall at 50/60 degC). But I'm a complete beginner with those things.

Again, thank you a lot for your help !

JMF

 

[phofman]

R61 Thinkpad with core duo T7100 and 3xUSB 2.0

Perhaps more than at the USB controller I would look at the USB receiver - the soundcards and their capabilities.

I have no information about the internal architecture of the R61, to define if there is only one USB host or more...

lsusb -t

 

[CharlieLaub]

I'm surprised that the board gets hot inside its plastic box (standard orange pi box), even at idle (I would say box wall at 50/60 degC). But I'm a complete beginner with those things.

I have an O-Pi PC. In the GUI desktop of the Ubuntu/Mate distro for it there is a control for the core frequency in the extreme bottom right corner. You can set it to a fixed frequency or implement a couple of levels of dynamic frequency that adjust to the load. I Think you right click on the control to select a new mode.

I used my board out in the open (no case). The SoC IC did get pretty warm to the touch. I found that the dynamic scaling helped this somewhat but still allowed the board to be responsive.

The O-Pi and the R-Pi 3 have increased the clock speed of the core. This means more heat generation. There are small Al heatsinks available on Ebay that you can just stick on to the top of the chip (they include an adhesive film) to increase heat dissipation.

 

[JMF11]

Perhaps more than at the USB controller I would look at the USB receiver - the soundcards and their capabilities.

lsusb -t

Hello,

Sorry to be a bit slow. I would have thought that if moving one amp from one plus to another, without changing any other parameter solve the problem, then it means that the problem is "upstream" in the laptop, and not at amp/USB receiver side. I'm curious to learn more about your idea.

Below the lsusb -t for the two configs.

Config that doesn't work:

/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 2, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
    |__ Port 2: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 2: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 2: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M

Config that works:

jmf@ubuntu:~$ lsusb -t
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 4, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 4, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 4, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 2, If 0, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 12M
    |__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M

JMF

 

[phofman]

I'm curious to learn more about your idea.

Well, the idea was if the soundcard was running at 1.5Mbps only, it would have switched the whole bus to this low speed, limiting the bandwidth too much. But the tree view of lsusb you provided shows 12M - full speed.

The first tree view shows both soundcards connected to bus 5, while the other one shows first soundcard to bus 5 and the second one to bus 4.

I do not know the reason for the low bandwidth message. Perhaps the initial config packet is too large to fit the 12Mbps frame size together with the other soundcard data packet. Both devices are isochronous therefore have the same priority on the bus - both packets must be accommodated in the same frame.