Ecasound DSP startup difficulties

Status
Not open for further replies.
Jump to Latest
#83
This is the result of my first measurement using the dsp. Its based on the
following commands

Code: 
ecasound -z:mixmode,sum -x \
         -a:pre -i:alsa,hw:Device, DEV=0 -pf:pre.ecp -o:loop,1 \
         -a:woofer,tweeter -i:loop,1 \
         -a:woofer -pf:woofer.ecp -chorder:1,2,0,0 \
         -a:tweeter -pf:tweeter.ecp -chorder:0,0,1,2 \
         -a:woofer,tweeter -f:16,4,44100 
         -o:alsa,surround51:CARD=Device,DEV=0

Filters are:
Code: 
# pre.ecp
pre = -el:RTparaeq,-8.5,82,2.6

# woofer.ecp
woofer = -el:RTlr4lowpass,1500 -el:RTlowshelf,4.0,150,0.71

# tweeter.ecp
tweeter = -el:RTlr4hipass,1500 -el:delay_0.01s,0.0019,1 -eadb:-4.5

Example copied from Richard Taylors tutorial

I test this by offering a testsignal generated by Arta on a separate PC via an additional Tascam soundcard to the Line in. The filtered output of the woofer and the tweater are send to an amplifier and a broadband speaker. The measurement microphone is connected to the Tascam that is read by Arta. This gives the picture below.
full.jpg


The result is as expected. 4th order filters at 1500 hz. I wil do some more experiments and see if I can improve the respons of this broadband speaker.
 
#87
 
#88
OK. So this would be the case:

A) Your DAC is playing TOSLINK ok, you can hear music.

B) While playing, you disconnect the toslink from the DAC and insert into digital input of the USB soundcard

C) While toslink still playing, you start recording with arecord into the wav

D) The recorded wav has correct length, but contains only zero samples.

If this is the case, your USB soundcard is broken.
 
#89
CharlieLaub said:
To be honest, this is a very, very cheap audio interface. I had one once... it's not all that good. I currently use "pro audio" interfaces that are intended for home recording studios. They can do simultaneous recording and playback, and the quality (THD, S/N ratio, etc) will be much better. See if you can get a used one on Ebay, etc. If you want some suggestions, send me a PM.
Click to expand...
I spend some time listening to this cheap soundcard. I use the line in input and applied a three way crossover but didn't filter one of the channels. I connected this channel to an amplifier and a pair of normal loudspeakers. So I expect to have a realistic result of the capabilities of the RPI/soundcard. The sound is not as bad as I expected. No distortion was audible and the whole frequency spectrum was there. The stereo image is somewhat flat and not as lively as I am used to and complex music is a little bit cloudy. Initially it played well but after a while I heard some popping/glitches in the sound and the terminal gave some warnings:
Code: 
WARNING: ALSA playback underrun, glitches in audio playback possible! Break was at least 320356662.99 ms long.
I used the -B:rt -tl command you learned me. Below the complete chainset:
Code: 
ecasound  -B:rt -tl -z:mixmode,sum -x \
          -a:pre1 -i:alsa,hw:Device,DEV=0 -pf:pre1.ecp -o:loop,1 \
          -a:pre2,woofer -i:loop,1 \
          -a:mid,tweeter -i:loop,2 \
          -a:pre2 -pf:pre2.ecp -o loop,2 \
          -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 \
          -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 \
          -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 \
          -a:woofer,mid,tweeter -f:16,6,44100 -o:alsa,surround51:CARD=Device,DEV=0
I think this is caused by the system, not by the soundcard, am I right? Is this a limitation of the RPI or can I improve the settings?
 
Last edited:
#90
Additionally on the previous post:

I monitored the system while playing. At warnings one or more CPU's show a short spike. I tried an easier chainsetup:
Code: 
ecasound -B:rt -f:16,2,44100 \
   -i:alsa,hw:Device,DEV=0 \
   -o:alsa,front:CARD=Device,DEV=0
While playing this I had no warnings and spikes on the CPU's.
 
#91
The pop/glitch problem that happened for your 3-way crossover but did not happen when you simply passed stereo audio thru the Pi is probably due to congestion on the USB bus itself, or the USB controller in the soundcard. The fewer channels that you try to send/receive over the USB bus, the less susceptible is the connection to demand from other processes on the Pi.

Are you running the Pi via the GUI, or as single user (no GUI, command prompt only)? The GUI uses resources that increase demand and you do not need to have the desktop open.

You can check to see the CPU usage of ecasound while you are running the crossover. In GUI, just open another terminal window and then run the command top. There is also a "system" tool that can show CPU usage for processes. In single user mode, run ecasound in the background by putting the character '&' at the end of the line. Once ecasound prints its initial output, hit return to see the command prompt. Then you can run top. To return ecasound to the foreground, first type 'jobs'. You will get a list of jobs running in the background. The ecasound process should be job #1. Type 'fg %1' (put job #1 in the foreground) to regain access to the process. You can then type control-C to kill ecasound.

I think you will see that even with your 3-way crossover the CPU usage will be quite low. It's usually the USB bus that causes glitches. A better soundcard will have a more capable USB controller.
 
#92
CharlieLaub said:
The pop/glitch problem that happened for your 3-way crossover but did not happen when you simply passed stereo audio thru the Pi is probably due to congestion on the USB bus itself, or the USB controller in the soundcard. The fewer channels that you try to send/receive over the USB bus, the less susceptible is the connection to demand from other processes on the Pi.

Are you running the Pi via the GUI, or as single user (no GUI, command prompt only)? The GUI uses resources that increase demand and you do not need to have the desktop open.

You can check to see the CPU usage of ecasound while you are running the crossover. In GUI, just open another terminal window and then run the command top. There is also a "system" tool that can show CPU usage for processes. In single user mode, run ecasound in the background by putting the character '&' at the end of the line. Once ecasound prints its initial output, hit return to see the command prompt. Then you can run top. To return ecasound to the foreground, first type 'jobs'. You will get a list of jobs running in the background. The ecasound process should be job #1. Type 'fg %1' (put job #1 in the foreground) to regain access to the process. You can then type control-C to kill ecasound.

I think you will see that even with your 3-way crossover the CPU usage will be quite low. It's usually the USB bus that causes glitches. A better soundcard will have a more capable USB controller.
Click to expand...
I use the system tool in the GUI to monitor the CPU. Playing the single pass audio through after some time also some glitches occured.

In the meantime I have some more experience using the filters of Richard Taylor. Using a measure microphone adaptions to the filter and measuring the result can be done really fast. This is even more convenient compared to a commercial product like a Hypex AS100.D where you have to upload the filter to two seperate units.
 
#93
phofman said:
If this is the case, your USB soundcard is broken.
Click to expand...
CharlieLaub said:
A better soundcard will have a more capable USB controller.
Click to expand...

It has been a while since I used this thread. In the meantime I have great progress with this subject. I buyed a second hand Asus Xonar U7 soundcard (no MKII) and have that working now with my RPI/ecasound/alsa setup. The soundquality is good and I have no problems any more with glitches etc. The card has an analogue line in that is useful for testing. Unfortunately it has only a spdif out an no spdif in. To play music I decided to install MPD. After some hickups I have that playing music now from my NAS via my new soundcard and I can control it by mpdroid, very convinient. The next thing now is to connect the MPD output with my digital filters in ecasound. This can be done by editing the mpd.conf file. I saw an example of Richard Taylor and tried to recreate that for my own filter but that didn't succeed.

I used the script below

Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:32:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -z:mixmode,sum -x -a:pre1 -pf:pre1.ecp -o:loop,1 -a:pre2,woofer -i:loop,1 -a:mid,tweeter -i:loop,2 -a:pre2 -pf:pre2.ecp -o loop,2 -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 -a:woofer,mid,tweeter -f:16,6,44100 -o:alsa,surround51:CARD=U7,DEV=0"
}
RT advised to use the format with 32 bit for noise reasons. Although I have this filter working with my line in its difficult to debug. Then I tried it with an easier script:

Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:16:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -f:16,2,44100 -o:alsa,front:CARD=U7,DEV=0"
Using
Code: 
sudo mpd --no-daemon --stderr --verbose ~/.config/mpd/mpd.conf
Initially it says
Code: 
avahi: Service 'Music Player' successfully established.
But when I try to play a file:
Code: 
output: opened plugin=pipe name="DSP crossover/eq" audio_format=44100:16:2
Warning: type DBC_NEVER_REACHED soft-assert '(null)' failed at
 -> eca-control-main.cpp:63 [static std::__cxx11::string ECA_CONTROL_MAIN::return_value_to_string(const eci_return_value*, int)]
errno: "DSP crossover/eq" [pipe] failed to play: Write error on pipe: Broken pipe
output: closed plugin=pipe name="DSP crossover/eq"
output: Failed to open audio output
What is wrong with the pipe setup?
Isn't it possible to refer to a filter script in a separate file?
 
#94
taita said:
I used the script below

Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:32:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -z:mixmode,sum -x -a:pre1 -pf:pre1.ecp -o:loop,1 -a:pre2,woofer -i:loop,1 -a:mid,tweeter -i:loop,2 -a:pre2 -pf:pre2.ecp -o loop,2 -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 -a:woofer,mid,tweeter -f:16,6,44100 -o:alsa,surround51:CARD=U7,DEV=0"
}
RT advised to use the format with 32 bit for noise reasons. Although I have this filter working with my line in its difficult to debug. Then I tried it with an easier script:

Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:16:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -f:16,2,44100 -o:alsa,front:CARD=U7,DEV=0"
Using
Code: 
sudo mpd --no-daemon --stderr --verbose ~/.config/mpd/mpd.conf
Initially it says
Code: 
avahi: Service 'Music Player' successfully established.
But when I try to play a file:
Code: 
output: opened plugin=pipe name="DSP crossover/eq" audio_format=44100:16:2
Warning: type DBC_NEVER_REACHED soft-assert '(null)' failed at
 -> eca-control-main.cpp:63 [static std::__cxx11::string ECA_CONTROL_MAIN::return_value_to_string(const eci_return_value*, int)]
errno: "DSP crossover/eq" [pipe] failed to play: Write error on pipe: Broken pipe
output: closed plugin=pipe name="DSP crossover/eq"
output: Failed to open audio output
What is wrong with the pipe setup?
Isn't it possible to refer to a filter script in a separate file?
Click to expand...

I believe that, for both scripts, the problem is that you do not specify the input for ecasound, so it does not accept the audio and throws an error. This might break the pipe.

Even if the audio input is just "stdin" you need to inform ecasound of that. Richard Taylor does this in his example, but you might have missed it. Specify the standard input like this:
Code: 
-i:stdin
and you will want to tell ecasound what audio format to expect using the -f command.

With those changes, the first MPD audio output you gave becomes this:
Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:32:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -z:mixmode,sum -x -a:pre1 -f:s32_le,2,44100 -i:stdin -pf:pre1.ecp -o:loop,1 -a:pre2,woofer -i:loop,1 -a:mid,tweeter -i:loop,2 -a:pre2 -pf:pre2.ecp -o loop,2 -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 -a:woofer,mid,tweeter -f:16,6,44100 -o:alsa,surround51:CARD=U7,DEV=0"
}

Try that and see if it works.
 
#95
CharlieLaub said:
I believe that, for both scripts, the problem is that you do not specify the input for ecasound, so it does not accept the audio and throws an error. This might break the pipe.

Even if the audio input is just "stdin" you need to inform ecasound of that. Richard Taylor does this in his example, but you might have missed it. Specify the standard input like this:
Code: 
-i:stdin
and you will want to tell ecasound what audio format to expect using the -f command.

With those changes, the first MPD audio output you gave becomes this:
Code: 
audio_output {
        type    "pipe"
        name    "DSP crossover/eq"
        format  "44100:32:2"
        mixer_type  "software"
        command "ecasound  -B:rt -tl -q -z:mixmode,sum -x -a:pre1 -f:s32_le,2,44100 -i:stdin -pf:pre1.ecp -o:loop,1 -a:pre2,woofer -i:loop,1 -a:mid,tweeter -i:loop,2 -a:pre2 -pf:pre2.ecp -o loop,2 -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 -a:woofer,mid,tweeter -f:16,6,44100 -o:alsa,surround51:CARD=U7,DEV=0"
}
Try that and see if it works.
Click to expand...
Thanks for the advice but unfortunately I still got the broken pipe error. I tried other things as well, but I'm running out of options. I found a tread with a comparable issue where you gave an advise to use loopback. NEW: the Active Crossover Designer for ecasound/LADSPA (ACD-L) - Techtalk Speaker Building, Audio, Video Discussion Forum
I'm thinking of using that to see if it helps.
 
#96
taita said:
Thanks for the advice but unfortunately I still got the broken pipe error. I tried other things as well, but I'm running out of options. I found a tread with a comparable issue where you gave an advise to use loopback. NEW: the Active Crossover Designer for ecasound/LADSPA (ACD-L) - Techtalk Speaker Building, Audio, Video Discussion Forum
I'm thinking of using that to see if it helps.
Click to expand...

I use an ALSA loopback connection in all my systems. I spotted an error in my posts about it on the PE TT thread that you linked to. I suggested using:
Code: 
type "alsa"
device "hw:CARD=Loopback,DEV=0"
...and...
Code: 
-i:alsa,"hw:CARD=Loopback,DEV=0"
But that won't work! The loopback is like a pipe with two ends, END#0 and END#1, called DEV=0 and DEV=1. If you put audio into one end you have to take it out from the OTHER end.

I usually write/put audio into the DEV=0 end and take it out (read) from the DEV=1 end. So please use this slightly modified code instead:
Code: 
type "alsa"
device "hw:CARD=Loopback,DEV=0"
In ecasound you should be able to use something like
Code: 
-i:alsa,"hw:CARD=Loopback,DEV=1"
The change is in the line above, the ecasound input, which is now reading data from DEV=1 of the loopback.

If you have not yet gotten the Xonar card to make any sounds at all, make sure to check that inputs and outputs are not muted via alsamixer.

If you get stuck, post here and I will help you.
 
Last edited:
#97
CharlieLaub said:
I use an ALSA loopback connection in all my systems. I spotted an error in my posts about it on the PE TT thread that you linked to. I suggested using:
Code: 
type "alsa"
device "hw:CARD=Loopback,DEV=0"
...and...
Code: 
-i:alsa,"hw:CARD=Loopback,DEV=0"
But that won't work! The loopback is like a pipe with two ends, END#0 and END#1, called DEV=0 and DEV=1. If you put audio into one end you have to take it out from the OTHER end.

I usually write/put audio into the DEV=0 end and take it out (read) from the DEV=1 end. So please use this slightly modified code instead:
Code: 
type "alsa"
device "hw:CARD=Loopback,DEV=0"
In ecasound you should be able to use something like
Code: 
-i:alsa,"hw:CARD=Loopback,DEV=1"
The change is in the line above, the ecasound input, which is now reading data from DEV=1 of the loopback.

If you have not yet gotten the Xonar card to make any sounds at all, make sure to check that inputs and outputs are not muted via alsamixer.

If you get stuck, post here and I will help you.
Click to expand...
I got it working. In MPD I use
Code: 
audio_output {
type "alsa"
name "MPD_output"
device "hw:CARD=Loopback,DEV=1"
format "44100:16:2"
}
Code: 
# Filter that uses the output of MPD
ecasound  -B:rt -tl -z:mixmode,sum -x \
          -a:pre1 -i:alsa,"hw:CARD=Loopback,DEV=0" -pf:pre1.ecp -o:loop,1 \
          -a:pre2,woofer -i:loop,1 \
          -a:mid,tweeter -i:loop,2 \
          -a:pre2 -pf:pre2.ecp -o loop,2 \
          -a:woofer -pf:woofer.ecp -chorder:1,2,0,0,0,0 \
          -a:mid -pf:mid.ecp -chorder:0,0,1,2,0,0 \
          -a:tweeter -pf:tweeter.ecp -chorder:0,0,0,0,1,2 \
          -a:woofer,mid,tweeter -f:16,6,44100 -o loop,3 \
          -a:output -i:loop,3 -eadb:3 -o:alsa,surround51:CARD=U7,DEV=0
I have some questions left:
In the logging of MPD I saw this
Code: 
alsa_output: opened hw:CARD=Loopback,DEV=1 type=HW
alsa_output: format=S16_LE (Signed 16 bit Little Endian)
alsa_output: buffer: size=16..524288 time=362..11888617
alsa_output: period: size=16..262144 time=362..5944309
alsa_output: default period_time = buffer_time/4 = 500000/4 = 125000
alsa_output: buffer_size=22050 period_size=4410
output: opened plugin=alsa name="MPD_output" audio_format=44100:16:2
output: Failed to open mixer for 'MPD_output'
Is the last sentence something to be concerned about?

The Xonar U7 soundcard gives good sound quality but a very low volume. I tried to increase the gain with -eadb in the filterscript but when I set this higher the output is getting distorted. Do I have more options to increase the volume?

In the PE TT thread there is some discussion about the sample frequency. Should I have advantage of changing the current 44/16? I tried some 24/88 and 24/96 tracks and they played well. I assume these are downsampled now in MPD?

I am considering to install Spotify on this RPI too. I found different options. Do you have any suggestions?
 
#98
An additional question. I added this to /etc/modules
Code: 
# Install the ALSA loopback 
sudo modprobe snd-aloop
# Path ladspa filters
export LADSPA_PATH=/usr/local/lib/ladspa:/usr/lib/ladspa
Unfortunately its not executed (or errouneaous?). Do I have to activate modules or something?
 
Status
Not open for further replies.
Top Bottom