Hello,
I'm working in my "first step" MPD/software DSP on laptop => 2xUSB amps=> 2x2ways speakers
I used all valuable informations provided here, so the software DSP is based on Richard Taylor's howto, ecasound and Charlie Laub's ACD Ladspa plusgins.
I also nee to use, as pointd out by phofman, an alsa virtual multi channel device to group my 2 USB amps in one device.
My 2 amps are device 1 and device 2. Adapted the file provided in Asoundrc - AlsaProject by changing the device numbers.
However, when I try to use my "multi" device, I get an error
Short translation: the hardware parameters could not be definded for the reading: broken pipe
I can address the individual devices...
Would you have advices about how to troubleshoot my issue?
Thanks in advance,
JMF
I'm working in my "first step" MPD/software DSP on laptop => 2xUSB amps=> 2x2ways speakers
I used all valuable informations provided here, so the software DSP is based on Richard Taylor's howto, ecasound and Charlie Laub's ACD Ladspa plusgins.
I also nee to use, as pointd out by phofman, an alsa virtual multi channel device to group my 2 USB amps in one device.
My 2 amps are device 1 and device 2. Adapted the file provided in Asoundrc - AlsaProject by changing the device numbers.
However, when I try to use my "multi" device, I get an error
Code:
speaker-test -D multi -c 4 -t wav
speaker-test 1.0.27.2
Le périphérique de lecture est multi
Les paramètres du flux sont 48000Hz, S16_LE, 4 canaux
fichier(s) WAV
La fréquence est 48000Hz (demandée 48000Hz)
L'intervalle de la taille du tampon est de 96 à 262144
L'intervalle de la taille de la période est de 48 à 131072
Taille max. de tampon 262144 utilisée
Périodes = 4
Les paramètres matériel n'ont pas pu être définis pour la lecture: Relais brisé (pipe)
Échec de la configuration des paramètres matériel: Relais brisé (pipe)
aplay -D multi chan_labels_4.wav -v
Lecture WAVE 'chan_labels_4.wav' : Signed 16 bit Little Endian, Fréquence 44100 Hz, 4 Canaux
aplay: set_params:1297: Les paramètres matériel n'ont pas pu être installés:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 64
CHANNELS: 4
RATE: 44100
PERIOD_TIME: (125011 125012)
PERIOD_SIZE: 5513
PERIOD_BYTES: 44104
PERIODS: (3 4)
BUFFER_TIME: 500000
BUFFER_SIZE: 22050
BUFFER_BYTES: 176400
TICK_TIME: 0Short translation: the hardware parameters could not be definded for the reading: broken pipe
I can address the individual devices...
Would you have advices about how to troubleshoot my issue?
Thanks in advance,
JMF
Code:
# create a virtual four-channel device with two sound devices:
# This is in fact two interleaved stereo streams in
# different memory locations, so JACK will complain that it
# cannot get mmap-based access. see below.
pcm.multi {
type multi;
slaves.a.pcm "hw:1,0";
slaves.a.channels 2;
slaves.b.pcm "hw:2,0";
slaves.b.channels 2;
bindings.0.slave a;
bindings.0.channel 0;
bindings.1.slave a;
bindings.1.channel 1;
bindings.2.slave b;
bindings.2.channel 0;
bindings.3.slave b;
bindings.3.channel 1;
}
# JACK will be unhappy if there is no mixer to talk to, so we set
# this to card 1. This could be any device but 1 is easy.
ctl.multi {
type hw;
card 1;
}
# This creates a 4 channel interleaved pcm stream based on
# the multi device. JACK will work with this one.
pcm.ttable {
type route;
slave.pcm "multi";
slave.channels 4;
ttable.0.0 1;
ttable.1.1 1;
ttable.2.2 1;
ttable.3.3 1;
}
# see above.
ctl.ttable {
type hw;
card 1;
}
Are you sure that hw:1,0 and hw:2,0 are the soundcards you think they are?
Have you checked if these devices work in adaptative mode ? If work in async it will probably break at once.
Btw, if you are using 2 identical usb devices the standard index or slot methods don't work and you will have to use the udev method to reliably identify your 2 usb devicesso as to bind each usb soundcard to a fixed usb plug ( for example on an Rpi i have 4 usb numbered from 0 to 3 and i need to make sure that Amp1 will be always plugged to usb 0 and Amp2 to usb 1, and not let the SO change this every time i boot).
alsa.opensrc.org
Have you checked if these devices work in adaptative mode ? If work in async it will probably break at once.
Btw, if you are using 2 identical usb devices the standard index or slot methods don't work and you will have to use the udev method to reliably identify your 2 usb devicesso as to bind each usb soundcard to a fixed usb plug ( for example on an Rpi i have 4 usb numbered from 0 to 3 and i need to make sure that Amp1 will be always plugged to usb 0 and Amp2 to usb 1, and not let the SO change this every time i boot).
alsa.opensrc.org
Last edited:
Hi,
The /proc/asound/card1/stream0 file gives:
So it is adaptative, as expected.
I can access with hw:1,0 and hw2,0 to both my amps and can get sound on them. So this is OK.
I understand te point with the naming of the USB devices. However, I understand that it is more a question between different boots than during a single session. I would like to have it work first in the "simple way" without the udev.
JMF
The /proc/asound/card1/stream0 file gives:
Code:
FX-AUDIO FX-AUDIO-D-802 at usb-0000:00:1d.0-1, full speed : USB Audio
Playback:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 4 OUT (ADAPTIVE)
Rates: 44100, 48000, 88200, 96000, 176400, 192000
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 4 OUT (ADAPTIVE)
Rates: 44100, 48000, 88200, 96000So it is adaptative, as expected.
I can access with hw:1,0 and hw2,0 to both my amps and can get sound on them. So this is OK.
I understand te point with the naming of the USB devices. However, I understand that it is more a question between different boots than during a single session. I would like to have it work first in the "simple way" without the udev.
JMF
Hello,
Thanks for the LC_ALL=C trick:
the aplay -v output, with plug:multi gives:
JMF
Thanks for the LC_ALL=C trick:
the aplay -v output, with plug:multi gives:
Code:
jmf@ubuntu:~/ecasound$ LC_ALL=C aplay -D plug:multi chan_labels_4.wav -v
Playing WAVE 'chan_labels_4.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Channels 4
aplay: set_params:1297: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 64
CHANNELS: 4
RATE: 44100
PERIOD_TIME: (125011 125012)
PERIOD_SIZE: 5513
PERIOD_BYTES: 44104
PERIODS: (3 4)
BUFFER_TIME: 500000
BUFFER_SIZE: 22050
BUFFER_BYTES: 176400
TICK_TIME: 0JMF
Sure, but as nobody really makes use of it for playing, nor of arecord for recording, nobody really knows its syntax in depth enough. Frankly, using -D or -Dplug...Personally i prefer to check if things work with any other soft i really use for playing or recording, basically sox and brutefir, because i messed enough with them before, and sometimes, not enough too....
Last edited:
Hello,
I just did quick tests tonight, following phofman proposals, but none worked. They all fail with the set_params:1297 error:
aplay chan_labels_4.wav -M -Dttable
aplay chan_labels_4.wav -M -Dplug:ttable
aplaplay chan_labels_4.wav -Dttable
aplay chan_labels_4.wav -Dttable
Too bad...
As my application is about filtering, maybe that I can try to get ecasound output to each individual amp, without merging them.
But I like the elegant virtual multi-channel device
JMF
I just did quick tests tonight, following phofman proposals, but none worked. They all fail with the set_params:1297 error:
aplay chan_labels_4.wav -M -Dttable
aplay chan_labels_4.wav -M -Dplug:ttable
aplaplay chan_labels_4.wav -Dttable
aplay chan_labels_4.wav -Dttable
Too bad...
As my application is about filtering, maybe that I can try to get ecasound output to each individual amp, without merging them.
But I like the elegant virtual multi-channel device
JMF
Stupid question: Are you sure about that chan_labels_4.wav ?
And yes my experience is that if you are familiar with ecasound, maybe it's the shortest path...
Last edited:
If you have two of the device listed in the CODE section above there really isn't a need to combine them. This is because they are communicating using USB adaptive mode so they will be sync'd even if addressed separately.
On the other hand if your devices were asynchronous, they will have their own internal clocks and will (sooner or later) drift out of sync. But this is not the case with the FX-AUDIO FX-AUDIO-D-802, which is deriving its clock from the USB bus clock itself. This is why I use multiple (inexpensive) adaptive mode DACs for multi-channel output from my Pi systems.
I suggest you try ecasound, sending the output of two of the channels to the first FX-AUDIO device and two more channels to the second FX-AUDIO device like this:
Code:
ecasound -i chan_labels_4.wav -o:loop,1 \
-a:device1,device2 -i:loop,1 \
-a:device1 -chorder:1,2 -o:alsahw,1,0 \
-a:device2 -chorder:3,4 -o:alsahw,2,0
Last edited:
JMF11, with aplay, when testing new virtual alsa devices I'm trying to create, I try -Dplug:mydevice as well as -D:mydevice. If it works with -Dplug: but not with -D: then you've learned a little about the problem. Also, when testing using aplay use the -vvv option to get detailed info on what alsa is trying to do.
Those working with alsa do
.. can make a big difference. Especially when the error is "Unable to install hw params". The plug plugin tries hard to align/convert your requested params with capabilities of the card.
Personally i prefer to check if things work with any other soft i really use for playing or recording, basically sox and brutefir, because i messed enough with them before, and sometimes, not enough too....
Yes for checking, unfortunately no for troubleshooting. Aplay allows changing all possible parameters which most of regular players have either hard-coded or rather difficult to modify. E.g. the very useful debug mode (-v, -vv, -vvv) listing detailed operations of all the plugins in the chain.
Once the configs are fine-tuned with diagnostics tools, the devices can be used by regular players without problems.
Interesting to learn that ecasound allows this, brutefir does not. Anyway this won't guarantee you control this way which physical unit is hw1 and hw2, because this is randomly decided by the OS at boot, so that you might get swapped channels L and R if using one amp / channel, or Highs and Lows if using one amp / way. The only way i know to save this issue, is using different usb devices which index will be set using their manufacturer and part code ( can be found by using lsusb). If these are the same, the udev method seems the only way to go.
JMF11 - perhaps the same problem as https://sourceforge.net/p/alsa/mailman/message/32679866/ ? Please check your dmesg.
Do the cards work OK individually?
I would try running aplay for each of them separately but at the same time so that both communicate over the same usb bus simultaneously.
Do the cards work OK individually?
I would try running aplay for each of them separately but at the same time so that both communicate over the same usb bus simultaneously.
Those working with alsa do
.. can make a big difference. Especially when the error is "Unable to install hw params". The plug plugin tries hard to align/convert your requested params with capabilities of the card.
Sure, but i am only using alsa at very basic hardware level, carefully avoiding plugins i don't really know how to use them, and can be the source of problems when used without knowing well enough alsa.
Btw, exploring the hardware capabilities through amixer controls/contents can also help, though i dont know in this case.
Imho, Ubuntu also does to many things without advising, with a view to give a better user experience, but this kind of over engineering in fact makes sometimes life more difficult...
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!
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.