Possibly taita set his new 5.1 soundcard to be used by the OS via a GUI control?
If typing pavucontrol at the command prompt does nothing you (taita) might need to install pavucontrol:
sudo apt-get install pavucontrol
Taita, the next problem is that only the default LADSPA plugins that come with ladspa-sdk are installed. If you try to use any of the plugins from Richard Taylor, ecasound will throw an error.
If you need help installing LADSPA plugins, just ask. I also wrote a plugin that some people seem to like. It does all the first and second order filters. See my sig for info.
If you need help installing LADSPA plugins, just ask. I also wrote a plugin that some people seem to like. It does all the first and second order filters. See my sig for info.
From what I have seen pulseaudio occupies all soundcards it detects in the system by default (incl. the snd-aloop one 🙂 ). It has to be told to ignore a specific card explicitely.
IMO such behaviour is correct since a user expects all soundcards being offered by the GUI sound configuration of his desktop environment (pavucontrol or other specific PA frontends).
I installed it.
I can play a wavfile by using ecasound sound.wav, but the chainsetup still fails. I think that should be the next step and than the filters.
I am unsure if
Code:
ecasound -B:rt -z:mixmode,sum -x -i:Flute.wav -f:16,2,44100 -o:alsa,plug:surround:DeviceA wave file contains a header that has all the audio formatting information. You do not need to include the "-f" formatting statement in your ecasound string. It could actually be wrong, which would cause an error. I would just leave it out.
Also, look back at what you posted in post #17 about the output from aplay -L. In your ecasound command you specify the output device
I do not see that listed in post 17, so it doesn't exist to the OS. Typos like that will kill you. It is good practice to copy and paste the name within the terminal window and you can avoid those annoying problems completely. The part to copy is the first line of each entry that is listed when you type aplay -L.
I think you might have meant to use:
plughw:CARD=Device,DEV=0
There really isn't a reason to use the plug device. I would just stick to "hw", and use:
hw:CARD=Device,DEV=0
e.g. in ecasound, the end part shoudl be:
-o:alsa,hw:CARD=Device,DEV=0
Try that.
Also, look back at what you posted in post #17 about the output from aplay -L. In your ecasound command you specify the output device
Code:
plug:surround:DeviceI think you might have meant to use:
plughw:CARD=Device,DEV=0
There really isn't a reason to use the plug device. I would just stick to "hw", and use:
hw:CARD=Device,DEV=0
e.g. in ecasound, the end part shoudl be:
-o:alsa,hw:CARD=Device,DEV=0
Try that.
Last edited:
Super!
ecasound -B:rt -z:mixmode,sum -x -i:Flute.wav -o:alsa,hw:CARD=Device,DEV=0 did it!
Ok, if you don't mind I come back to the filters. I need more filters and instructions you told me.....
And there is one annoying error left: why do mp3 files fail?
I checked flac and it played but with interruptions:
(audioio-db-client) WARNING: Underrun in reading from "Adele.flac". Trying to recover.
I have to stop for today. Thanks for the progress and I will try to make a filter. CU!
Last edited:
Not sure. I don't use ecasound to play files. I use a "player" for that. In my systems I use an alsa system called a loopback that connects the output of my player to the input of ecasound. It is also possible to pipe the output between programs.
Also, in:
Code:
ecasound -B:rt -z:mixmode,sum -x -i:Flute.wav -o:alsa,hw:CARD=Device,DEV=0Anyway, it's late where you are. Good work for today. We can take up the LADSPA filter stuff another time.
Last edited:
I use ecasound per Richard's article, and had some buffering issues some time ago. Please check your system load, (use top or uptime) to see if your processor is able to handle the load. You may also want to increase the buffer size. The error is a "buffer runderrun", meaning that the buffer has gone empty, and you get an interruption until more data gets into the buffer.
This is the ecasound command I am using in my OrangePi, with a 7.1 sound card, 2-way xover plus a stereo pair without crossover:
code
command "ecasound -b:1024 -z:db -z:mixmode,sum -x -a😛re -f:s32_le,2,44100 -i:st
din -o:loop,1 -a😛re2,full -i:loop,1 -a😛re2 -o:loop,2 -a:woofer,tweeter -i:loop
,2 -a:woofer -pf:/etc/woofer.ecp -chorder:1,2,0,0,0,0 -a:tweeter -pf:/etc/tweete
r.ecp -chorder:0,0,0,0,1,2 -a:full -pf:/etc/full.ecp -chorder:0,0,1,2,0,0 -a:woo
fer,tweeter,full -f:f32_le,6,44100 -o:stdout | sox -q -c 6 -r 44100 -b 32 -e fl
oat -L -t raw - -e signed -c 6 -b 16 -t alsa surround51😀evice"
/code
This is the ecasound command I am using in my OrangePi, with a 7.1 sound card, 2-way xover plus a stereo pair without crossover:
code
command "ecasound -b:1024 -z:db -z:mixmode,sum -x -a😛re -f:s32_le,2,44100 -i:st
din -o:loop,1 -a😛re2,full -i:loop,1 -a😛re2 -o:loop,2 -a:woofer,tweeter -i:loop
,2 -a:woofer -pf:/etc/woofer.ecp -chorder:1,2,0,0,0,0 -a:tweeter -pf:/etc/tweete
r.ecp -chorder:0,0,0,0,1,2 -a:full -pf:/etc/full.ecp -chorder:0,0,1,2,0,0 -a:woo
fer,tweeter,full -f:f32_le,6,44100 -o:stdout | sox -q -c 6 -r 44100 -b 32 -e fl
oat -L -t raw - -e signed -c 6 -b 16 -t alsa surround51😀evice"
/code
Recently I solved a weird problem I was having with buffering. I'm running a stereo 3-way crossover from a Pi 2, and slowly over a time period of many hours (e.g. 10 hours) a lag would develop between the source and the audio emanating from the loudspeakers that was on the order of 4-5 seconds. If I stopped play, the audio would continue for several seconds. I experimented a bit with some settings and the cause turned out to be internal buffering by ecasound. Now I disable this with
Code:
-z:nointbufSince you do not specify dbsize it seems that ecasound uses the value of zero! I don't think it is doing anything.
Also, the buffering problems you are experiencing might be due to all the piping you are employing. I think you are calling this code from within MPD, which pipes MPD's output to ecasound, and then piping ecasound's output to sox. If you are using sox just to implement dither, I think you might prefer no dither and unbroken audio to the very subtle and likely inaudible effect of adding dither. You could try having ecasound send the audio directly to the DAC and see how that works...
Charlie, it's been a couple years since I touched that MPD configuration. It's working just fine the way it is, and I really see little reason to "fiddle" with it. True, I could not really hear what the dither did when I added it in, but I think I will leave it there. I have plenty of processing power for it, and it all works nicely...
I tried to do some more testing with
I could recognize the channels but the quality is very poor. This concerns me about the final result. Anything wrong with this command?
I found another tuturial with some additional information http://www.google.nl/url?sa=t&rct=j...d=1484390896&usg=AOvVaw2vwHZlzGIzA5PRciZSWDKP
In this document a loopback is configured. I don't see this back in the page of Taylor. Apparantly there are different approaches. What is the best one?
Code:
ecasound -B:rt -tl -i chan_labels_6.wav -f:16,6,44100 -eadb:-24 -o alsa,surround51:DeviceI found another tuturial with some additional information http://www.google.nl/url?sa=t&rct=j...d=1484390896&usg=AOvVaw2vwHZlzGIzA5PRciZSWDKP
In this document a loopback is configured. I don't see this back in the page of Taylor. Apparantly there are different approaches. What is the best one?
The "quality" could be do to things besides ecasound... but I have some tips and things to try.
Remember, you should use the ALSA "name" for the soundcard EXACTLY as listed in the output of "aplay -L". Instead of "surround51😀evice" you might try using "surround51:CARD=Device,DEV=0".
Also, like I mentioned before, I would not use the "-f" audio format statement here. Why? Because you are using a wave file as input, and it will tell ecasound what it's audio parameters are (because ecasound will encounter and read the file's header, which contains this info). It might be the case that the file is recorded at 48kHz but you specified 44.1kHz and so the data must be resampled. Ecasound uses very primative "resampling" by default that could make the sound quality seem bad. Try it again, this time without the format statement. Any better?
Also, what is the new soundcard that you are using? Can you link to it?
Subscribed.. 🙂
Great thread, I'm trying this stuff in parallel with my rPI + Piano2.1. Even though there are lots of resources, pulling it all together and debugging it is not intuitive.
Great thread, I'm trying this stuff in parallel with my rPI + Piano2.1. Even though there are lots of resources, pulling it all together and debugging it is not intuitive.
I made some progress:
- I configured the two way chain setup based on the tuturial of Richard Taylor.
- I entered three filtersections for pre, woofer and filter based on the same
The result is playing a flac file and I can clearly hear the difference between highpass and lowpass. So this important piece succeeded now.
Good to mention (and obvious for people who know linux very well) that the three filtersections have to be stored in batch files by using the 'touch' and 'sudo nano' commands to enter the editor.
My next stap was trying to connect with my source using the glassfiber SPDIF input of the soundcard. Unfortunately I can't get this to work. I use
Code:
-i:alsa, iec958:CARD=Device,DEV=0Cheap, but it seems to cover the specifications. Is it possible that I need to install a driver to release SPDIF In?
What do I need additional on the filters of Richard Taylor (you mentioned that earlier)?
Last edited:
There is no requirement to use "touch" or "nano" to create a shell script or batch file. A script file is just a text file that has the "executable" bit set to true. You can create this text file, and edit it at any time, using whatever text editor you would like or prefer. Make sure to name the file with an extension of ".sh" for "shell script". To make a text file executable, you issue the command:
Code:
chmod +x filename.extThe alsa input command you listed:
Code:
-i:alsa, iec958:CARD=Device,DEV=0I happen to have the same soundcard. It is capable of SPDIF loop (just tested), alsamixer must be switched to PCM Capture = IEC958 In. The spdif output is hooked to first two output channels, i.e. duplicated from stereo. Of course volume control applies to analog outputs only.
The digital input works only for 48kHz satisfactorily, 44.1kHz produces clicks. IMO limitation of the USB chip. Analog output is audibly OK up to 96kHz (no measurements done).
The digital input works only for 48kHz satisfactorily, 44.1kHz produces clicks. IMO limitation of the USB chip. Analog output is audibly OK up to 96kHz (no measurements done).
The space was a typo, sorry for that.
Unfortunately I can't get this to work. Your suggestions on alsamixer are not clear for me. Below a picture of the current settings of the mixer and the filter script I use.
I also tried the line in. I'm unsure what setting I should use for that as aplay -L doesn't give me a clear line in. Tried different things amongst
Code:
-i:alsa,hw:CARD=Device,DEV=0Just look at the picture - what is your PCM Capture value and what value did I write in my previous post?
- Status
- Not open for further replies.