Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mark_NL]

Solved? see below

update:
No clicks and glitches anymore, but stuttering at the end of each song.
Please some directions for analyzing this problem.

(newbee with linux , but learning fast)

---------------------------------
(Original)

Hi there,
I can't get my (dyinhk) XMOS USB based DIY-DAC (dyinhk es9018K2M) to work well with a PI 2. The good news is it plays everthing I throw at it (even DSD).  

But never without a glitch or click once a while, any ideas?

Its better if the output is set to 16 bits (but that's not the idea...);
played around with buffer times and ALSa audio settings in MC;
from local sd card or network doesn't seem to make a difference.

tried Rasbian and ARCH-ARM (both 3.18.10), MC-ARM 20.0.0.81
the pi is clocked at 1000/500/500/2

tried a lot (often old) tweaks from forums as: dwc_otg.speed=1, ect, etc

hooked up to an very old laptop with Debian/MC20 it works without glitches.
hooked up to  windows/MC20 real magic is happening (I mean it never heard that from my speakers)
without the Xmos USB/i2s converter, the dac i2s pins direct to GPIO pins works without glitches but with very (VERY) loud plops before start and after stop playing a song.
With Volumio and Archiphile it plays clean ( even up sampled to 32bit/192kHz) but no magic...

pi@raspberrypi ~ $ lsmod | grep snd
snd_bcm2835            18665  0
snd_usb_audio         103940  1
snd_usbmidi_lib        19617  1 snd_usb_audio
snd_hwdep               5902  1 snd_usb_audio
snd_seq_midi            4406  0
snd_seq_midi_event      5375  1 snd_seq_midi
snd_rawmidi            18265  2 snd_usbmidi_lib,snd_seq_midi
snd_pcm                73475  3 snd_bcm2835,snd_usb_audio
snd_seq                53078  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device          5628  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer              17784  2 snd_pcm,snd_seq
snd                    50998  10 snd_bcm2835,snd_usb_audio,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_seq_device

pi@raspberrypi ~ $ cat /proc/asound/card0/stream0          # 24/96khz flac
DIYINHK DIYINHK USB Audio 2.0 at usb-bcm2708_usb-1.4, high speed : USB Audio

Playback:
  Status: Running
    Interface = 1
    Altset = 1
    Packet Size = 127
    Momentary freq = 96013 Hz (0xc.0068)
    Feedback Format = 16.16
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
    Data packet interval: 125 us
  Interface 1
    Altset 2
    Format: S16_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
    Data packet interval: 125 us
  Interface 1
    Altset 3
    Format: SPECIAL DSD_U32_BE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
    Data packet interval: 125 us


Second question (I'm just learning Linux),

Can MC use the available “hardware”mixer  ? ;

pi@raspberrypi ~ $ amixer
Simple mixer control ' Playback',0
  Capabilities: volume pswitch penum
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 127
  Front Left: 94 [74%] [-33.00dB] Playback [on]
  Front Right: 94 [74%] [-33.00dB] Playback [on]
Simple mixer control ' Playback',1
  Capabilities: volume volume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Capture channels: Mono
  Limits: 0 - 127
  Mono: 127 [100%] [0.00dB] Playback [on]

(i’ve chosen this USB/dac combo because of this volume control, all other music distros (MPD) don't do a good job with software volume control, MC does this extremely good but at low volumes the digital control of the DAC slightly better)

[Mark_NL]

Bumping this up because I’m still wondering if someone got it working on a PI 2 with an USB Audio Class 2 device

[bob]

Bumping this up because I’m still wondering if someone got it working on a PI 2 with an USB Audio Class 2 device

There are none here that will work on the Pi.

As for the mixer, if you switch MC to the "System Volume" you will be controlling the master PCM mixer.
If there isn't one or it's elsewhere, you'll need to use internal volume or the system alsamixer.

[Mark_NL]

There are none here that will work on the Pi.

That's a pitty, i’ll keep track on developments on this issue  

[Mark_NL]

Short update

One setup always outperformed everything else I tried but could not reproduce why;

I found it: setting the scaling governor of the cpu’s to performance makes a huge difference

[Mark_NL]

Testing environment:
Vanilla Rasbian with “mwillems” headless solution , overclock 1000/500/500/2
default “ondemand” cpu govenor’s
Track Change gaped 1 sec ; don’t use gapless for sequential album tracks.
playing a 24bit/96hkz album from other network MC20 (send to > pi > play)


Probable Cause : (please comment)
typical image of htop just after track change in playlist in my setup is 24-96 std.png

So, CPU1 (=CPU0 in the real world) goes through the roof. Probably MC20 gets in the way of system tasks Edit: system task’s get in the way of MC20; to my knowledge (correct me if I’m wrong) the PI binds the handling of the hardware IRQ’s, dwc_otg (USB) included, to CPU0. Everything (or at least MC) come’s to a grinding hold..
 
Assigning MC20 to CPU1, 2 & 3 (= 2, 3 & 4 in htop) with taskset the track changes looking like this (24-96 taskset & - taskset2.png)




 
Dropout’s are gone  
Downside is MC is running on a PI 1.75, does anyone know a more elegant solution?  

[Mark_NL]

Some stress testing: from 96 to 348 kHz and other stuff

Just hanging in there, but not a glitch!  

[mwillems]

That's very clever.  It hadn't occurred to me that the Pi wouldn't handle interrupt offloading in a sensible way, but that's not necessarily surprising given that Raspbian is still the same as it was for the Pi 1 (which only had a single CPU). 

I wonder if you'd see the same issues on Arch or Debian hardfloat?  Probably not worth the time to go through all that since you've found a solution already, but I'd be very curious if they "just worked" or if it's a kernel issue.  FWIW, I saw slightly improved performance on an Arch installation, but an Arch installation is not for the faint of heart 

Congrats on finding a solution for your issue!

[bob]

So what this boils down to is that the first core has to handle all of the interrupts and that you push MC off of that core and everything is hunky dorey?

Interesting. MC is not using CPU priorities on linux (but does on Windows and Mac). Perhaps making them work would help. Since a user can't raise priority from 0, we would map it so that some threads would drop priority. You'd think system interrupts would already be handled at a higher priority. Maybe a real-time linux kernel build here would help?

[Mark_NL]

Congrats on finding a solution for your issue!

Thanx

So what this boils down to is that the first core has to handle all of the interrupts and that you push MC off of that core and everything is hunky dorey?

It works for me, could be it’s specific behavior of this usb receiver.  There’s a lot going on at a track change, maybe it generates a bulk of interrupts. I have to admit, after some update’s it improved a lot and was working quite well. Never flawless, especially with 24/96.

Interesting. MC is not using CPU priorities on linux (but does on Windows and Mac). Perhaps making them work would help. Since a user can't raise priority from 0, we would map it so that some threads would drop priority. You'd think system interrupts would already be handled at a higher priority. Maybe a real-time linux kernel build here would help?

Not a real idea where you talking about;
I tried about every dist/kernel could get hands on, including an RT kernel. Didn’t make a difference  to the good..

[mwillems]

So what this boils down to is that the first core has to handle all of the interrupts and that you push MC off of that core and everything is hunky dorey?

Interesting. MC is not using CPU priorities on linux (but does on Windows and Mac). Perhaps making them work would help. Since a user can't raise priority from 0, we would map it so that some threads would drop priority. You'd think system interrupts would already be handled at a higher priority. Maybe a real-time linux kernel build here would help?

I think the system interrupts are handled at a higher priority than MC, which is why MC's playback is dropping out when there are a lot of interrupts.  The issue seems to be that MC is trying to compete with the interrupts on the same core and losing (at least occasionally).  It might be helpful to use a system monitor like munin to graph interrupts against CPU usage to look for correlations, etc.  

But it's hard to know what fix is best without being able to repro; I haven't been able to reproduce this issue with seven different DACs and three different Pi's.  I can't even reproduce this on a Pi B+ which is running with a much smaller margin for error.  So it's got to be fairly hardware dependent.

[Hilton]

There are some known issues with USB audio and dropouts due to interrupt issues.  It seems to be a hard one to solve because of the Pi architecture.
Next time I get some errors in my logs I'll show you what I mean.  It does appear to be hardware specific and dependant on how many devices you're loading up on the USB ports, including Network activity because the onboard NIC uses USB too.

BTW, if you clone into bcmstat you can get a whole bunch of useful info out of the pi, including interrupt workload.

•CPU fequencies (ARM, Core, h264)
•Temperature (current and peak)
•IRQ/s
•Network Rx/Tx
•GPU mem usage
•CPU load (including individual cores when available)
•RAM usage (with/without swap)


git clone https://github.com/MilhouseVH/bcmstat.git

then run the below to get detailed stats (you might need to chmod +x bcmstat.sh too)

sudo ./bcmstat.sh xgcd10

[Hilton]

Example output below.

Starts with Pi idle for 2 samples, then playing MP3 for 2 samples, then the IRQs jumps into the red with a stereo 88khz FLAC @ 11:28:49 11:28:59, then idle again.

[Hilton]

If you want to know more about the USB issues, this is the best thread to read about bus collisions and lost USB transactions and the improvements being made with changes to FIQ and dwc_otg.

Things are much better with the latest changes but not perfect.


https://www.raspberrypi.org/forums/viewtopic.php?t=70437

[outis]

I've read in a (german) forum about problems with the compatibility of different (USB-)DACs:

- identical installation on the rpi(2).
- DAC a: no problems
- DAC b: a lot of problems here discussed.

If possible try another DAC.

[Mark_NL]

24/96 Track change;

Is this an normal or high amount of interups per sec?

@ Outis: can you give a link?

[mwillems]

That does seem like a lot.  

I don't use the bcmstat script, but I do track interrupts/IRQs over time using munin,* which provides nice graphs and an additional breakdown on the source of the interrupts (not just a raw number of interrupts).  My system averages about 3k interrupts/sec during playback, and the maximum interrupts munin recorded over the last week was about 7K, of which about half (3.5 k) were USB-related.  This is a system with a USB DAC, a USB harddrive, and a USB wi-fi dongle attached, so that's probably to be expected.  I haven't experienced any dropouts.

You're seeing interrupt numbers over 12K, which is almost double my max recorded, so I wouldn't be surprised that you're getting dropouts. It also looks like you're pushing the Pi's network interface to it's limits, which may also be part of your problem.  It looks like the interrupt spikes correlate to your system trying to pull a significant amount of data over the network in a hurry (80 or 90MB or so over 10 or 12 seconds).  Have you tried playing back a file on local storage (just as a test) to see if you still get drop outs?

If it's just an issue of MC trying to pull the file across just as fast as it can, there are some ways to address the issue (network throttling, using a better network adapter, etc.).  

*Munin provides lots of really useful info on a wide variety of system topics nicely presented in graphical form and comparable over time; the only thing it doesn't do nicely out of the box on a Pi is take system temperature, but I wrote a plugin for that if anyone wants one. Munin can be configured to provide almost arbitrary granularity down to 1 second intervals.  Setup/configuration for a single node in Raspbian is not too tough if folks want to try it, but I don't have time right now to to write up a how-to.  

[outis]

@Mark_NL

Please have a look on this thread:
http://www.aktives-hoeren.de/viewtopic.php?p=98723#p98723

Notabene: JRiver MC is much more critical than squeezelite/mpd discussed in that thread because of consuming much more ressources. At the moment I'm playing a 192/24-file and MC is consuming ca. 50% CPU summarized from 4 CPUs of my rpi2, Squeezelite or mpd not more than ca. 20% with the same 192/24.

But: MC plays without any problems on my rpi2 (ArchLinux) when it is used as renderer. If the GUI is used via vnc then the additional network traffic is obviously generating a lot of troubles.

[Mark_NL]

Danke!

Geheimtip for using MPD like player and get really good sound, stream PCM from MC. (again: works for me)

If the GUI is used via vnc then the additional network traffic is obviously generating a lot of troubles.

Switch the Spectrum analyzer off.

[outis]

Geheimtip for using MPD like player and get really good sound, stream PCM form MC.

Yes! One of my favorites. (BTW: ...and the reason for my question in this thread: http://yabb.jriver.com/interact/index.php?topic=97961.0). But ncmpc(pp) isn't bad too.

Switch the Spectrum analyer off.

What's that? Never used...

[PrinterPrinter]

Hello Mark,
I think I have a similar issue to the one you had of drops and pops occasionally.

I'm using a Pi2 +HifiBerry Digi + > Toslink > Hugo DAC. My Berry is connected with WiFi but it's the only USB device connected.

Can I ask you (or anyone else) to write simple, n00b friendly instructions on how to set this up on the Pi? I think I vaguely understand what this is about - but wouldn't know where to begin...

Thanks very much,

[Mark_NL]

To be honest, I didn’t write down the “code” on purses as this issue is very specific for my dac.

I don’t think it is helpful for you as it cannot be reproduced with a hiffiberry dac + ;  this on spite of somewhat similar jumps in interrupts.

As it doesn’t involve any superuser privileges, it won’t hurt to give it a try (BTW: witch is weird, back in the day’s on the multiuser UNIX systems you needed permission of that real-life superuser to run your program on a fast “empty” CPU – that’s how I came to this idea in the first place  ?)

To test this you start MC (in a terminal on the PI) with the command:  
taskset –c 1-3 mediacenter20 /mediaserver.  

So what’s happening here: with taskset you tell the OS (raspbian) to run a process (program)  on a specific (range of) CPU’s: “–c” means where gonna tell the OS we are talking about CPU numbers ; “1-3” is the range of cpu’s we want to give to the process we start with the command “mediacenter20 /mediaserver”.

My thesis is: there are high priority system-processes (hardware interrupts) which exist just a very short time and always get handled by CPU0. A user program as MC20 has to get out of the way.

If you’re using a script to start MC automatically you can change the command in there.  –OR-
copy this script  and make the change in this new script;  edit your crontab (crontab –e) to use the new script just created. Close MC if it is still running and wait for the next (automatic) startup  

Sorry maybe not as noob friendly as you hoped, it is a kind of experimental  so it’s recommendable to get a grasp what you’re doing (I learned a lesson )

[Mark_NL]

It also looks like you're pushing the Pi's network interface to it's limits, which may also be part of your problem.  It looks like the interrupt spikes correlate to your system trying to pull a significant amount of data over the network in a hurry (80 or 90MB or so over 10 or 12 seconds).  Have you tried playing back a file on local storage (just as a test) to see if you still get drop outs?

Yes i tried to play form the sd card and a powered USB HDD drive didn't make much difference;
Never the less, you are right IRQ's drop to 5,5K when playing form the local source!

I cant think of a way to influence the network traffic  ?

[mwillems]

I haven't done much fiddling with it myself, but I'd suggest looking into the "tc" command-line tool (for "traffic control"), which allows you to cap network traffic on interfaces.  I'd try limiting the bandwidth to, say, 40Mb and see if that helps.  That kind of thing.

Additionally, some folks have found that using a USB to ethernet converter actually resulted in better network performance than the integrated ethernet NIC: http://www.midwesternmac.com/blogs/jeff-geerling/getting-gigabit-networking

But I wouldn't run out and buy an adapter until I'd tried limiting ethernet traffic.

[Mark_NL]

I haven't done much fiddling with it myself, but I'd suggest looking into the "tc" command-line tool (for "traffic control"), which allows you to cap network traffic on interfaces.  I'd try limiting the bandwidth to, say, 40Mb and see if that helps.  That kind of thing.

hmmm have some reading to do

But I wouldn't run out and buy an adapter until I'd tried limiting ethernet traffic.

No, next bet would be another platform Banana pi / Orange pi / ?

[mwillems]

hmmm have some reading to do
No, next bet would be another platform Banana pi / Orange pi / ?

I tried fiddling with three or four other platforms, but most of the other platforms I've engaged with don't have all the "kinks" ironed out in part because they have much smaller communities and market capitalization.  The Pi has been by far the most stable of the DIY ARM platforms I've tried (which is saying something because the Pi still has its share of quirks).

The most frustrating thing about some of the ARM platforms I've tried is that really random things don't work that are not at all obvious from the documentation.  It's only once you realize that they're broken and go searching through the forums for a fix that you realize that it's a) a known issue and b) is not going to be fixed anytime soon.

I've not yet had an issue with the Pi I couldn't fix; Not so with, for example, my ODROID's or the beaglebone I played with. 

[Hilton]

Yeah I agree RPi is the most supported and most stable DIY ARM platform.
I was looking for other more powerful ARM processors with better HDMI support but came to the conclusion best to stick with RPi and wait for some of the known issues to be solved.
OR Go with the new Intel NUCs and HDMI stick.

By the time you add HDD, wifi, power supply, memory card and a few other things the RPi is starting to get close to what you can do with an Intel entry level NUC or Intel HDMI stick.

Ultimately, the perfect low power low cost MC capable renderer doesn't exist yet, all the options have trade-offs, but I'm optimistic that will change in the next 18 months.

[Mark_NL]

I haven't done much fiddling with it myself, but I'd suggest looking into the "tc" command-line tool (for "traffic control"), which allows you to cap network traffic on interfaces.

just for notice;

Throttling with tc on the PI give’s no relief, logic as prefect received  packages getting dropt for speed renegotiation.
The max amount of IRQ’s drop drastic if the speed is capped on the streaming side.

For now i’l stick just to taskset solution. After some hours of listening (not the test setup; arch arm) it didn’t miss a beat with 16/44.1 flac’s. With 24/96 flac’s  still have occasional (once in 2-3hours)  dropouts, 2 or 3 core’s top to 100%:

IRQ/s     RX B/s     TX B/s         cpu0     cpu1    cpu2      cpu3
=====  ============   ========== ====== ======
4,271  1,638,198     24,858       21.51  25.41   98.05    97.07
3,086            677       1,126        9.20  19.94 100.00  100.00
1,640         1,444          204        4.61    1.69 100.00  100.00
1,363  1,267,195      17,173      13.95    7.26   97.77    99.55
2,241 11,712,909    307,741      79.67  45.80   29.34   38.54
3,081            148          219        9.15   3.32    13.53    11.10

[juergen99]

Bumping this up because I’m still wondering if someone got it working on a PI 2 with an USB Audio Class 2 device

There are none here that will work on the Pi.

I have a Pi2 running MC20 outputting via USB to a Schiit Bifrost DAC.  As far as I know it's an asynchronous USB Class 2 device.  I am also getting dropouts.  I just set it up a few days ago.  I noticed that when I switched wifi cards last night it semed to improve.  This weekend I'll try and take a more methodic approach and try different sampling rates between the two wifi cards and onboard wired to see if there are any consistant differences.   

[JimH]

Try changing the Audio settings.  MC may be set to "Automatic".  Try the 16 something option.

[Mark_NL]

I have a Pi2 running MC20 outputting via USB to a Schiit Bifrost DAC.  As far as I know it's an asynchronous USB Class 2 device.  I am also getting dropouts.  I just set it up a few days ago.  I noticed that when I switched wifi cards last night it semed to improve.  This weekend I'll try and take a more methodic approach and try different sampling rates between the two wifi cards and onboard wired to see if there are any consistant differences.    

The bifrost has a C-media USB receiver who can do both UAC1 & 2, probable it gets recognized as UAC2.
Make sure your home-wifi network is OK: signal strength, ect ...; If you are living in a densely populated aria like me try to find a channel that suites best (I receive 23 AP's in the livingroom).

Due to the implementation of usb and wired network on the PI a wifi solution is likely to work best with MC-arm. MC seems to try to pull a lot of the track in when it starts, on a wired connection this seems to be a bit to much for the PI.  (as far as I understand it...)

Try to set the CPU Governor to performance (how to is in the quick start)


Playing 16 bit's gives relive, but as stated before : that's not the general idea. Especially if you have use the internal volume control as MC doesn't get hold of the available ALSA mixer.
(if there is an ALSA mixer for your dac, it should be visible in the volume applet on the task bar; or in a terminal type: alsamixer  and press F6 to see all the mixer divices)

[Mark_NL]

UPDATE:

found a setup which plays everything without missing a beat. Even DSD converted to PCM 32bit 352,8 kHz or bitsteaming (DoP).

It’s a arch-arm setup (kernel 4.1.8-1) and needs some tinkering:
- CPU govener on perfomane (1000 MHz)
- MC runs on cpu 1-3
- Network speed is capped at 40 Mb/s at the server side
- The last leap forward is getting rid of Openbox. I’m running Fluxbox now the cpu load droped significant.

(BTW the window buttons work too)

[bob]

UPDATE:

found a setup which plays everything without missing a beat. Even DSD converted to PCM 32bit 358 kHz or bitsteaming (DoP).

It’s a arch-arm setup (kernel 4.1.8-1) and needs some tinkering:
- CPU govener on perfomane (1000 MHz)
- MC runs on cpu 1-3
- Network speed is capped at 40 Mb/s at the server side
- The last leap forward is getting rid of Openbox. I’m running Fluxbox now the cpu load droped significant.

(BTW the window buttons work too)

Minimize and Maximize work? So that was a Openbox issue of some kind. Interesting...

[Mark_NL]

Minimize and Maximize work? So that was a Openbox issue of some kind. Interesting...

Yes!
found that out while trying XFCE on an other arm board, but don't need a DE so went for Fluxbox

(Rasbian is LXDE it uses openbox too...)

[Mark_NL]

Upgraded to MC 21, although that threw me back a little bit.

The ultimate solution, as it stands now, is using another arm-board : Orange PI

(https://yabb.jriver.com/interact/index.php?topic=101069.msg701085#msg701085)

With the Orange PI you get what you pay for (it's really cheap) so if you're not prepared to thinker a bit I recommend against it.
But it does the job flawless, it passed the test by steaming music for 5 day's in a row (with MC 20, due to the current memory leak in MC21)


Benchmark of a, for stability, underclocked (max 1,2 Ghz) Orange PI Plus

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 7.585 seconds
    Single-threaded floating point math... 14.015 seconds
    Multi-threaded integer math... 4.861 seconds
    Multi-threaded mixed math... 8.280 seconds
Score: 547

Running 'Image' benchmark...
    Image creation / destruction... 2.589 seconds
    Flood filling... 4.162 seconds
    Direct copying... 5.058 seconds
    Small renders... 2.680 seconds
    Bilinear rendering... 3.004 seconds
    Bicubic rendering... 0.838 seconds
Score: 1200

Running 'Database' benchmark...
    Create database... 4.219 seconds
    Populate database... 12.441 seconds
    Save database... 1.605 seconds
    Reload database... 0.605 seconds
    Search database... 11.739 seconds
    Sort database... 9.128 seconds
    Group database... 5.509 seconds
Score: 475

JRMark (version 20.0.129): 741

[Hilton]

For anyone else experiencing pops clicks I changed the ALSA audio Device Settings as follows and it cured them for my new DAC.
Everything plays flawlessly now upto 32/384 including DSD64 and DSD128 DoP.

Not sure why and it might not fix anyone else's problems but it did for me.


Pi2-ALSA-buffer by Hilton, on Flickr

[Mark_NL]

For anyone else experiencing pops clicks I changed the ALSA audio Device Settings as follows and it cured them for my new DAC.
Everything plays flawlessly now upto 32/384 including DSD64 and DSD128 DoP.

Yes the default 500000 (ms?) does exceed the max alsa buffersize of 131072 (Kb?) if you playing very hires media;
(cat /proc/asound/cardX/pcm0p/sub0/hw_params  # while playing)
but that didn't seem to bother in my case...


Do you play from a local source? or to be more specific:
How does it preform playing over the DLNA network?

[Hilton]

Do you play from a local source? or to be more specific:
How does it preform playing over the DLNA network?

Im using Local SSD - playing over wifi or Ethernet is still getting some dropouts pauses and crackling though.

Looks like we need to wait for the next Pi version to hopefully have this fixed or change to another similar board to get hi-res over the network reliably.