Heyo JR, Thanks for the thoughts, but my problem is something a bit 'deeper' than those potential faults. My error message is a simple "segmentation fault" on the terminal command line. That is all I get even if I try to play internal files via sox-play at debug level 4. Meanwhile, playing anything to hw:0,0 works fine (but no crossover, of course). I'll worry about it later...
Volumio is good - I tried it. But if the hacking gets too annoying, consider Squeezelite. That's my player of choice at the moment. I had always managed my music in iTunes on a mac, and the Logitech Media Server that feeds Squeezelite is seamless with respect to iTunes libraries. But it is good with other libraries as well. Plugins for streaming services are available. My wife uses Spotify, so I set that up. Custom playlists from the spotify app can be loaded into squeezelite and played without issue. The only possible negative is that the best mobile control apps are third party. I like iPeng, and have it on my phone and on an iPad. Remote controls are not required, because a very usable html-based localhost application can control the system from whatever machine is serving the player. Again, I like the whole package better than Volumio (as of 6 mo. ago) and sound quality is the same as MPD-based players. ...a possible alternative if the Volumio/kernel hacking stops being fun...
F.
Volumio is good - I tried it. But if the hacking gets too annoying, consider Squeezelite. That's my player of choice at the moment. I had always managed my music in iTunes on a mac, and the Logitech Media Server that feeds Squeezelite is seamless with respect to iTunes libraries. But it is good with other libraries as well. Plugins for streaming services are available. My wife uses Spotify, so I set that up. Custom playlists from the spotify app can be loaded into squeezelite and played without issue. The only possible negative is that the best mobile control apps are third party. I like iPeng, and have it on my phone and on an iPad. Remote controls are not required, because a very usable html-based localhost application can control the system from whatever machine is serving the player. Again, I like the whole package better than Volumio (as of 6 mo. ago) and sound quality is the same as MPD-based players. ...a possible alternative if the Volumio/kernel hacking stops being fun...
F.
Just thinking here... have you ever been able to get my LADSPA plugins to work, that is to NOT throw the seg fault? If they always behave that way it could be that that are not compiled correctly, but correctly enough to create the so file, which then causes the exception.
Can you clarify that? Thanks.
I really appreciate your thoughts on this question! I compiled the 1.03 filter set without editing Makefile. And using ecasound, I just executed one instance of filter 21 without apparent problem.
In most cases, any syntax or other problem within an ALSA plugin throws an error when you execute 'aplay -L'. For ACDf testing I'm using a simple 2-way, 4 filter, 4 channel crossover. In this case no issues pop up until one sends ALSA a signal.
Well, it seems like I can't get the kernel modules to work on volumio or moode and frankly i don't feel like rebuilding the kernel again, so I'm going to try this squeezelite thing. How is the performance of that player on the pi? Does it take a lot of resources?
Sent from my iPhone using Tapatalk
Sent from my iPhone using Tapatalk
Of course, I don't know about the Pi, but with the BBB a 3-way @ 44.1kHz (RT plugins) uses less than 20% of the CPU. Thus, it functions for sources up to 192kHz.
https://en.wikipedia.org/wiki/Logitech_Media_Server
TUTORIAL: Installing Squeezelite player on Raspbian | Squeezing a Raspberry Pi
Announcing iPeng 9 - Support for iPad Multitasking, iPad Pro and more
http://forums.slimdevices.com/showt...zeplay-emulator-for-linux-(alsa-only)/page295
http://manpages.ubuntu.com/manpages/trusty/man1/squeezelite.1.html
...and there are a few more options by executing 'squeezelite --help'
Last edited:
Is this still with one filter per channel, e.g. one LR4? Did you ever figure out how to chain filters in ALSA? I don't recall ever seeing this figured out for ALSA - apologies if it has been... IMHO if you can't chain multiple filters you can only construct very rudimentary crossovers.
Yes, you need the 'server' software - Logitech media server - to supply Squeezelite. It's lightweight code (not a machine) and doesn't duplicate any media content. You can (most likely) point it to whatever physical media on your network happens to contain your music library. In my case, everything happens to be on my Mac Pro, but I don't believe that is at all necessary. There are other configurations. I could run the server software on a physical stand-alone media server if I chose. But as it turned out for me, I didn't even have to change how I manage my media on the Mac - I just added the server program, configured the preferences, and it all ran! Logitech media server's preferences offer extensive options.
Very true, Charlie. With the RT series, I'm using a 4th order L-R for bass/mid and a 2nd order L-R for mid/tweet. Each is just one 'filter' so they can go in one plugin whose output can then go to the t-table for routing. In the case of ACDf filters, what we will have to do is add subsequent plugins that continue to modify each 'channel' as needed. In other tests I've added plugins for signal delay, or EQ, etc. and they work just fine on the frequency bands created for each driver. Instead of those manipulations, why not just add more ACDf manipulations? That approach keeps the channels organized by number - so the input and output of each subsequent plugin is the same channel number.
Another approach would be to open up a bunch of extra channels and, for multiple filters within one plugin, input from one channel number and output to a different channel. It seems equivalent, but we know from experience that the final output channel mapping gets kwazy!
So probably the best solution when complex chains are called for is to restrict the number of channels and organize by writing multiple serial plugins.JR's current code does some of both, restricted to 8 channels total. That's a very manageable situation.
Bottom line - I don't think it is going to be hard. We just have to experiment and see what performs best.
Cheers, amigo!
Frank
Hey Franco, that looks like fun
QQ: I'm trying out squeezelite, running the squeezebox LMS from the same pi. But the audio isn't playing through the filter. I'm trying to use this tutorial, but editing the settings file doesn't work. Is squeezelite looking for a different syntax?
QQ: I'm trying out squeezelite, running the squeezebox LMS from the same pi. But the audio isn't playing through the filter. I'm trying to use this tutorial, but editing the settings file doesn't work. Is squeezelite looking for a different syntax?
Excellent! If you like Squeezelite enough to go with it on a more permanent basis, you might consider running it as a service. FYI, I actually kill and restart it when I change to headphones - where no crossover is wanted. When I use it with a crossover I start it using: 'squeezelite -z -C 1 -o default -a 8192:2048::0'
In any case, run 'top' and see if your CPU draw is lower...
Enjoy!
In any case, run 'top' and see if your CPU draw is lower...
Enjoy!
Last edited:
I'm using the tutorial linked above which has (handily) the services already built in
here's top for you
Code:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4474 pi 20 0 13968 9016 3036 S 15.2 1.0 51:49.81 squeezelite-arm
427 squeeze+ 20 0 100192 94164 6616 S 2.0 9.9 5:16.31 squeezeboxserve
6276 root 20 0 0 0 0 S 0.7 0.0 0:04.04 kworker/u8:2
6446 pi 20 0 5112 2392 2028 R 0.7 0.3 0:00.21 top
43 root 1 -19 0 0 0 S 0.3 0.0 1:44.31 VCHIQ-0
44 root 1 -19 0 0 0 S 0.3 0.0 1:51.56 VCHIQr-0
423 root 0 -20 0 0 0 S 0.3 0.0 0:00.80 kworker/2:1H
6318 root 20 0 0 0 0 S 0.3 0.0 0:03.00 kworker/u8:1
1 root 20 0 5468 3924 2724 S 0.0 0.4 0:07.74 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:01.36 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0.0 0.0 0:05.80 rcu_sched
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0.0 0.0 0:00.04 migration/0
10 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/1
11 root 20 0 0 0 0 S 0.0 0.0 0:00.29 ksoftirqd/1
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
14 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/2
15 root 20 0 0 0 0 S 0.0 0.0 0:00.25 ksoftirqd/2
17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H
18 root rt 0 0 0 0 S 0.0 0.0 0:00.03 migration/3
19 root 20 0 0 0 0 S 0.0 0.0 0:00.40 ksoftirqd/3
21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
23 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
24 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf
26 root 20 0 0 0 0 S 0.0 0.0 0:00.01 khungtaskd
27 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
29 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
30 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockdHey franco,
I'm having issues with 24/96 flac files. There's a lot of underruns/overruns with audio dropouts. Its fine with normal bitrates and this doesn't happen when playing the same song in ecasound
running squeezelite-status
Could this possibly be a user issue also? I see the session is opened for root and closed for root. Does squeezelite attempt to downsample the audio? That's my other hypothesis.
Thanks,
James
I'm having issues with 24/96 flac files. There's a lot of underruns/overruns with audio dropouts. Its fine with normal bitrates and this doesn't happen when playing the same song in ecasound
Code:
ecasound -i /media/usbstick/music/The\ Four\ Seasons/01\ Concerto\ pour\ deux\ violons\ et\ violoncelle\ RV\ 578a\ -\ Adagio\ e\ spiccato.flac -f:24,2,96000 -z:nodb -b:80running squeezelite-status
Code:
● squeezelite.service - Squeezelite LMS player
Loaded: loaded (/etc/systemd/system/squeezelite.service; enabled)
Active: active (running) since Sun 2016-03-06 17:42:58 PST; 4min 30s ago
Process: 1548 ExecStop=/etc/init.d/squeezelite stop (code=exited, status=0/SUCCESS)
Process: 1985 ExecStart=/etc/init.d/squeezelite start (code=exited, status=0/SUCCESS)
Main PID: 2023 (squeezelite-arm)
CGroup: /system.slice/squeezelite.service
└─2023 /usr/bin/squeezelite-armv6hf -n rubymusic -m 00 c1 41 17 09 31 -s 127.0.0.1 -a 80
Mar 06 17:42:57 rubymusic sudo[1997]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/squeezelite-armv6hf -t
Mar 06 17:42:57 rubymusic sudo[1997]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mar 06 17:42:57 rubymusic sudo[1997]: pam_unix(sudo:session): session closed for user root
Mar 06 17:42:57 rubymusic squeezelite[1985]: Starting: /usr/bin/squeezelite-armv6hf -n rubymusic -m 00:c1:41:17:09:31 -s 127.0.0.1 -a 80
Mar 06 17:42:57 rubymusic squeezelite[1985]: with pidfile: /var/run/squeezelite-armv6hf.pid
Mar 06 17:42:57 rubymusic squeezelite[1985]: Wait until player is connected to Squeezebox server before sending play command
Mar 06 17:42:57 rubymusic squeezelite[1985]: Not connected after 1 seconds...
Mar 06 17:42:58 rubymusic squeezelite[1985]: Player connected to Squeezebox server after 2 seconds
Mar 06 17:42:58 rubymusic squeezelite[1985]: Sending power on command for player rubymusic (00:c1:41:17:09:31) to Squeezebox server (127.0.0.1 9090)
Mar 06 17:42:58 rubymusic systemd[1]: Started Squeezelite LMS player.Could this possibly be a user issue also? I see the session is opened for root and closed for root. Does squeezelite attempt to downsample the audio? That's my other hypothesis.
Thanks,
James
Likely (well at least my first guess) is your buffering. From the ecasound man page:
Note is should be a power of 2 (you are using 80). So I would crank up the buffering to 1024 or 2048 or even 4096 so that it is working smoothly, and then try to reduce this value until you just get an occasional problem and then increase to the next power of 2.
Heyo JR,
I think Charlie is on the right track. I see that your 'squeezelite...' call has -a set at 80. The unusual thing about Squeezelite is that the buffer and related settings can be in time or in bytes. Look at the man page under the -a options. You will see that there are four variables. I've seen wonkiness here depending on the compiling. The second number of the -a options is the period. I suggest one quarter of the buffer (= 4 periods). The third variable is better left blank. The fourth variable is whether to use mapped memory. Better to not use that. So, as you will see in my command to call squeezelite, I am using '-a 8192:2048::0' If that works you can try reducing both the buffer and the period by the same factor. I left mine big based on CPU efficiency. There was absolutely no audible difference between large and smaller buffers - unlike some other systems with which I have worked. So sound differences would be something for you to verify in your system (and report here). But also pay attention to how buffer size affects CPU demand.
If we are in left field here, shoot back the outcome of messing with buffer & period and we'll scratch the head some more.
Oh BTW, I run everything as root.
F.
I think Charlie is on the right track. I see that your 'squeezelite...' call has -a set at 80. The unusual thing about Squeezelite is that the buffer and related settings can be in time or in bytes. Look at the man page under the -a options. You will see that there are four variables. I've seen wonkiness here depending on the compiling. The second number of the -a options is the period. I suggest one quarter of the buffer (= 4 periods). The third variable is better left blank. The fourth variable is whether to use mapped memory. Better to not use that. So, as you will see in my command to call squeezelite, I am using '-a 8192:2048::0' If that works you can try reducing both the buffer and the period by the same factor. I left mine big based on CPU efficiency. There was absolutely no audible difference between large and smaller buffers - unlike some other systems with which I have worked. So sound differences would be something for you to verify in your system (and report here). But also pay attention to how buffer size affects CPU demand.
If we are in left field here, shoot back the outcome of messing with buffer & period and we'll scratch the head some more.
Oh BTW, I run everything as root.
F.
Last edited:
Heyo JR,
I think Charlie is on the right track. I see that your 'squeezelite...' call has -a set at 80. The unusual thing about Squeezelite is that the buffer and related settings can be in time or in bytes. Look at the man page under the -a options. You will see that there are four variables. I've seen wonkiness here depending on the compiling. The second number of the -a options is the period. I suggest one quarter of the buffer (= 4 periods). The third variable is better left blank. The fourth variable is whether to use mapped memory. Better to not use that. So, as you will see in my command to call squeezelite, I am using '-a 8192:2048::0' If that works you can try reducing both the buffer and the period by the same factor. I left mine big based on CPU efficiency. There was absolutely no audible difference between large and smaller buffers - unlike some other systems with which I have worked. So sound differences would be something for you to verify in your system (and report here). But also pay attention to how buffer size affects CPU demand.
If we are in left field here, shoot back the outcome of messing with buffer & period and we'll scratch the head some more.
Oh BTW, I run everything as root.
F.
Ah, you gentlemen are spot on as always.
@Charlie, I was testing out "80" as the buffer in Ecasound because I wasn't sure about what the "80" does in squeezelite's settings. As Franco mentions, it's not quite what I thought... according to the man pages, it's time in mS, so I bumped mine up to 80 and the number of periods to 4, and (perhaps crucially) the sample rate to 24. One thing I found with ecasound is that the bigger buffer isn't necessarily better. At 4096, the audio is so choppy using ecasound that Vivaldi sounds like Nine Inch Nails
Now I'm running the equivalent of
Code:
-a 80:4:24:0BTW Charlie,
Here's my .asoundrc file, hopefully you find it interesting
Code:
#asound rc new version jrubinstein - experimental with charlies plugin
pcm.!default {
type plug
slave.pcm filtereq
}
ctl.!default {
type hw
card 0
}
pcm.filtereq {
type ladspa
slave.pcm filtercross
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [28 1 6 120 1 1 1] }
}
1{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 -6 164 4 1 1] }
}
2{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 -6 250 4 1 1] }
}
3{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [26 1 6 193 5 1 1] }
}
4{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [28 1 6 120 1 1 1] }
}
5{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 -6 164 4 1 1] }
}
6{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 -6 250 4 1 1] }
}
7{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [26 1 6 193 5 1 1] }
}
8{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz to act as subsonic filter
}
9{
label ACDf
policy none
input.bindings.0 "Input"
output.bindings.0 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz
}
10{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz to act as subsonic filter
}
11{
label ACDf
policy none
input.bindings.1 "Input"
output.bindings.1 "Output"
input { controls [22 1 0 40 1 1 1] } #2nd order highpass at 40 hz
}
}
}
pcm.filtercross {
type ladspa
slave.pcm speaker
path "/usr/lib/ladspa"
channels 8
plugins
{
0 {
label ACDf #lowpass for woofer output to channel2
policy none
input.bindings.0 "Input"
output.bindings.2 "Output"
input { controls [21 -1 0 300 0.5 1 1] } # [filter type polarity dbgain frequency q]
}
1 {
label ACDf #lowpass for woofer output to channel3
policy none
input.bindings.1 "Input"
output.bindings.3 "Output"
input { controls [21 -1 0 300 0.5 1 1] } #2nd order lowpass at 300hz
}
2 {
label ACDf #highpass for tweeter output to channel4
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 -1 -13 3000 1 1 1] } #2nd order highpass at 3000 hz
}
3 {
label ACDf #highpass for tweeter output to channel4 filter 2
policy none
input.bindings.0 "Input"
output.bindings.4 "Output"
input { controls [22 1 0 3000 1 1 1] } #2nd order highpass at 3000 hz
}
4 {
label ACDf #highpass for tweeter output to channel4
policy none
input.bindings.1 "Input"
output.bindings.5 "Output"
input { controls [22 -1 -13 3000 1 1 1] } #2nd order highpass at 3000 hz
}
5 {
label ACDf #highpass for tweeter output to channel4 filter 2
policy none
input.bindings.1 "Input"
output.bindings.5 "Output"
input { controls [22 1 0 3000 1 1 1] } #2nd order highpass at 3000 hz
}
6 {
label ACDf #lowpass1 for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [21 1 -4 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz -4db cut
}
7 {
label ACDf #lowpass2 for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [21 1 0 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz
}
8 {
label ACDf #highpass for mid output to channel0
policy none
input.bindings.0 "Input"
output.bindings.6 "Output"
input { controls [22 1 0 300 0.5 1 1] } # 2nd order highpass at 300 hz
}
9 {
label ACDf #lowpass1 for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [21 1 -4 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz -4db cut
}
10 {
label ACDf #lowpass2 for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [21 1 0 3000 0.707 1 1] } # 2nd order lowpass at 3000 hz
}
11 {
label ACDf #highpass for mid output to channel1
policy none
input.bindings.1 "Input"
output.bindings.7 "Output"
input { controls [22 1 0 300 0.5 1 1] } # 2nd order highpass at 300 hz
}
}
}
pcm.speaker {
type plug
slave {
pcm "t-table"
channels 8
rate "unchanged"
}
}
pcm.t-table {
type route
slave {
pcm "hw:0,0"
channels 8
}
ttable {
0.0 0 # audio = left woofer channel = left front
1.1 0 # channel in.channel out on/off
2.0 1 #left bass this gives me the low filter for left woofer onto channel 0 = front left
3.7 1 #right bass = SBR
4.6 1 #left tweeter = SBL
5.5 1 #right tweeter = Surr Right
6.4 1 #left mid = surr left
7.3 1 #right mid = center
}
}
pcm.plughw.slave.rate = "unchanged";Now I just have to get Shairport configured and running correctly and my life is complete.
Thank you both so much for helping me figure all this craziness out
I owe you both a beer next time you are in San Jose
Perfect is good! However, 80/4=20 periods! Default is 4. If using milliseconds, I then suggest -a 80:20::0. For the squeezelite version I am using, the maximum buffer is 500msec so you could always bump it up from 80 and AFAIK no need for strict multiples of 2. ...ideally, just divide buffer length by 4 for the period size. Finally, at least try avoiding the bit specification unless there is another specific reason to pad...
'top' is your friend in choosing among sonically equivalent configurations.
Frank
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.