Print

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

[bob]

http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.101-armhf.deb

20.0.101 Fixed playback of ALAC files.

20.0.99 Added support for Media Keys.

20.0.93 Fixes the issue with crashing on the RPi 1 (arm6l devices).
           Changed the /mediaserver mode to startup minimized to try to save on processing power required while doing playback.

20.0.91 Includes the /mediaserver mode switch change that doesn't hide the UI but still prevents blocking. This means you can use it with a dummy X Server but still connect to it remotely to change the settings.

For the list of other changes, see the general debian linux release announcement for linux specific changes and the windows announcement for multiplatform changes.

This is a full version of MediaCenter for Debian Wheezy on ARM  for your testing pleasure.  It will time out on June 10, 2015.

We may or may not release an end user package for ARM in the future. Much will depend on if it requires any support outside of generic linux support.

This is compiled to run on the RPi 1 as a minimal system (arm6l). It will also run on an arm7 box (i.e. RPi 2, cubox) but is not and will not be optimized for that platform.

Feedback welcome.

[mwillems]

This is compiled to run on the RPi 2 as a minimal system (arm6l).

Quick question: the RPi 2 is an arm7 platform; the original RPi was arm 6.  So is this build still arm 6 optimized? Or did you rebuild on the Pi 2?

Just trying to figure out if I need to redo my benchmarks 

[bob]

Quick question: the RPi 2 is an arm7 platform; the original RPi was arm 6.  So is this build still arm 6 optimized? Or did you rebuild on the Pi 2?

Still aiming at the 6l.
Just swapped out the pi 1 for the pi 2 in the build system.
They haven't built a arm7k Raspbian system yet, just the kernel.

We aren't going to try to support a bunch of cpu's with this and the JRMarks really aren't that different between the 2.

[mwillems]

Still aiming at the 6l.
Just swapped out the pi 1 for the pi 2 in the build system.
They haven't built a arm7k Raspbian system yet, just the kernel.

We aren't going to try to support a bunch of cpu's with this and the JRMarks really aren't that different between the 2.

I figured, but I wanted to make sure. I mentioned this in the other thread, but running an RPi 2 on Arch ARM (which is fully arm7h), my JRMark was about 20% higher than on Raspbian (635 on Arch vice 523 on Raspbian).  Obviously it doesn't necessarily follow that gains from JRiver optimization for arm7h would be that significant, and it sounds they're not?  Regardless, thanks for clarifying.

[Hilton]

Is this just an update inline with other Linux code base updates or have you added/changed any features for ARM?

[JimH]

I think it's the same Linux code, just compiled for ARM.

[Hilton]

I think it's the same Linux code, just compiled for ARM.

Ok so we should check the most recent Linux change log then.

[mwillems]

I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian).  I didn't experience any regressions, FWIW.  Let me know if there's anything specific you'd like tested.

[bob]

Ok so we should check the most recent Linux change log then.

yes and for the changes in general, the windows log.

[bob]

I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian).  I didn't experience any regressions, FWIW.  Let me know if there's anything specific you'd like tested.

Thanks, I'm just looking for breakage right now.

[Hilton]

I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian).  I didn't experience any regressions, FWIW.  Let me know if there's anything specific you'd like tested.

Is there any reason not to use Arch?  I'd like to try it out if its stable as I've always liked Arch.

[mwillems]

Is there any reason not to use Arch?  I'd like to try it out if its stable as I've always liked Arch.

In this context, I haven't seen any significant downsides once everything is running.

Arch requires much more manual configuration on the front end, but that's true anytime you use Arch for anything.  The Arch ARM base has virtually nothing preconfigured except SSH.  You have to setup your locale and timezone in the shell, install X, install your desktop environment, configure wi fi yourself, and repackage the Mediacenter .deb, but once that's all done, it's done.  I've done enough Arch installs that I can be done in about 40 minutes, but the first time took a few hours.  If you're not used to systemd, there can be a bit of a learning curve with that too.

Pros:

1) Newer software and sound drivers
2) Arm7 optimized so there are mild performance gains
3) Minimal base, so it's only running what you tell it to run.

Cons:

1) More work to setup (the flip side of minimal base)
2) It's a rolling release, so it will occasionally break.  I've been running Arch on my main PCs for close to a year, and have only seen one instance where an update broke things in a serious way and required manual intervention.  I haven't seen any breakage on the Pis yet, but that day will probably come sooner or later.  

Debian Jessie is pretty up to date right now (because it just had a package freeze in november), so if you just want newer packages *and* stability you can install Jessie on the Pis.  I installed jessie on several Pi 1's and it worked well (although some of the core packages are still wheezy packages because the pi foundation isn't moving on to Jessie yet).

[bob]

I've having some trouble with this build on the Pi 1. It's segfaulting when I switch to the audio view. Sounds like perhaps a imaging issue.
Anyway backing off to 66 works fine.

[Hilton]

I gave the Pi2 a pretty thorough stress test today.

I have 3 zones configured:
Pi-Default > HDMI
Pi-E17DAC > USB
Pi-Bluetooth > BT

Playing 320K MP3s to all zones at once and using JRemote playing to "this device" on the iPhone.
(so 4 streams at once)

The Pi was running @ ~15% CPU once all streams are running and peaks @ 80% CPU with a few streams starting together.
When one zone goes to the next track the CPU goes to 40% for a few seconds before dropping back to 10-15%

It didn't stop or stutter until I started all 4 streams at once, then it took 15 seconds to stabilise and was fine even with 2-3 streams overlapping when going to the next track.
Not bad for the little Pi2!

It plays 176K and 192K FLAC from the USB stick ok to a single zone transcoding to 44.1K or 96k, playing the same tracks from the attached USB HDD it would occasionally buffer.
This might me due to brown-outs on the USB bus to the HDD as it's really right on the limit running a HDD without a powered USB hub for the HDD. (the Pi has a soft power down poly fuse which causes brown-outs on the USB bus if you push it too far, this is to protect the processor and kernel from panicking and crashing.

96K and 44K FLACs are fine.

2ch SACD to PCM is close but not quite there, and multi-channel is out of the question for FLAC or SACD.

This is using the Pi2 as a server which is not really what it's designed for. Its nice to know you can use it as a server for MP3s and lower samplerate FLACs though.
Using the Pi as a renderer with transcoding on the server it played everything upto 24bit/96K FLAC from the server.

[JimH]

That's surprisingly good.  Thanks for taking the time to report what you found.

[mwillems]

It plays 176K and 192K FLAC from the USB stick ok to a single zone transcoding to 44.1K or 96k, playing the same tracks from the attached USB HDD it would occasionally buffer.
This might me due to brown-outs on the USB bus to the HDD as it's really right on the limit running a HDD without a powered USB hub for the HDD. (the Pi has a soft power down poly fuse which causes brown-outs on the USB bus if you push it too far, this is to protect the processor and kernel from panicking and crashing.

I did some testing on this today myself. I had no problems playing resampled 192K FLAC files (resampled by the pi to 96K or 44K) from an external HDD plugged directly into the Pi today, but plugging in extra peripherals caused buffering issues like you described.  With just my external HDD, a wifi dongle and my DAC plugged in, I managed to listen through an entire album resampled from 192K down to 96K with no dropouts or pauses, and CPU utilization remained low.  If I plugged in a USB stick or another HDD, I could replicate your buffering issue.  Using a powered USB hub with plenty of current allowed me to run two external HDDs at the same time without harming Pi Playback while resampling.

Obviously not all external HDDs have the same power requirements, but I think it's likely to be a brown out/power issue, not a bus speed issue as I had no problems pulling 192K FLACs from an external HDD (provided I kept my power load down).  I was doing local playback, not serving, so that may be a distinction (depending on how you tested), but the fact that you got good playback with a USB stick seems like a red flag for a power issue.

In more general notes, I got in about six hours of playback testing today at the office with zero issues; local playback on the pi 2 worked for all file types tested without breaking a sweat. With a 2amp power supply, I managed to power the Pi itself, a wifi dongle for control, and my external DAC (an ODAC).  I'll post some pics over in the other thread.

[Chanh]

Hi Guys,

Have recently moved to JRiver Linux, and with JRemote, there is simply no going back for me. This interface simply the best there is for both sound quality & user interface. I have gone through virtually most there are in the audiophile World. e.g JPlay, Foobar, ....., squeezebox, LMS,...., Volumio, RuneAudio, PiCoreplayer via LMS......., you got the point.

Many thanks to Bob & the team for your great efforts with the ongoing development.

Currently, I have also experimenting this build on my Pi2, and is working great! I use ENC-Viewer via iPad to do all the desktop configurations and importing library. JRemote for navigating the library and playing the music.

Here comes my question, has anyone able to get this to work with Banana Pi or BeagleBone Black? Grateful for some technical assistance getting either BPi or BBB to work?

Many thanks,
Chanh

PS: It is sad to see this project terminate at June.

[Chanh]

Here comes my question, has anyone able to get this to work with Banana Pi or BeagleBone Black?

Just to inform all that I have now able to get JRiver to work with BananaPi under Ulbutun distro.

[Hilton]

PS: It is sad to see this project terminate at June.

Nice work on bananaPi!
I wouldn't worry about the demo expiring in June. Im pretty sure by then Jim will be happy to take our money! Its still experimental for now because there are still bugs to be ironed out.

[Hilton]

Obviously not all external HDDs have the same power requirements, but I think it's likely to be a brown out/power issue, not a bus speed issue as I had no problems pulling 192K FLACs from an external HDD (provided I kept my power load down).  I was doing local playback, not serving, so that may be a distinction (depending on how you tested), but the fact that you got good playback with a USB stick seems like a red flag for a power issue.

It is indeed not a bus bandwidth issue, its a brown-out issue. I was getting the rainbow square popping up in the top right corner of the screen which indicates a power issue. 
When my HDD was on a powered USB hub in the office today it was fine. 

Yesterday I tested USB stick and HDD performance with HDParm and its more than adequate. 
I got 400MB/s cached read from USB stick and 250MB/s from HDD with about 28MB/s buffered read from both USB stick and USB HDD.

So no bottleneck there unless your getting USB brown-outs which will cause buffering because the HDD momentarily looses power during the brown-outs.

[Hilton]

I had a complete lockup this afternoon. Here's the tail of the syslog.
HDD was on the powered hub at the time.

Syslog Errors:

Code: [Select]

Mar 10 16:02:30 raspberrypi kernel: [11160.363230] usb 1-1.5.1: new full-speed USB device number 42 using dwc_otg
Mar 10 16:02:30 raspberrypi kernel: [11160.511991] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512026] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512046] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512065] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512084] usb 1-1.5.1: config 1 has no interface number 2
Mar 10 16:02:30 raspberrypi kernel: [11160.524235] usb 1-1.5.1: New USB device found, idVendor=1852, idProduct=50d0
Mar 10 16:02:30 raspberrypi kernel: [11160.524264] usb 1-1.5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 10 16:02:30 raspberrypi kernel: [11160.524283] usb 1-1.5.1: Product: FiiO USB DAC-E17
Mar 10 16:02:30 raspberrypi kernel: [11160.524301] usb 1-1.5.1: Manufacturer: FiiO
Mar 10 16:02:30 raspberrypi kernel: [11160.541054] input: FiiO FiiO USB DAC-E17 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1852:50D0.0012/input/input17
Mar 10 16:02:30 raspberrypi kernel: [11160.541696] hid-generic 0003:1852:50D0.0012: input,hidraw0: USB HID v1.00 Device [FiiO FiiO USB DAC-E17] on usb-bcm2708_usb-1.5.1/input0
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] log.c: Invalid UTF-8 string following below:
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] #004: ▒▒il#006
Mar 10 16:02:35 raspberrypi rsyslogd-2177: imuxsock lost 7948 messages from pid 18986 due to rate-limiting
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error


[JimH]

We often put a timeout on early builds of something new so that a year later, when someone has a problem, we know there build is less likely to be broken.

[bob]

I had a complete lockup this afternoon. Here's the tail of the syslog.
HDD was on the powered hub at the time.

Syslog Errors:

Code: [Select]

Mar 10 16:02:30 raspberrypi kernel: [11160.363230] usb 1-1.5.1: new full-speed USB device number 42 using dwc_otg
Mar 10 16:02:30 raspberrypi kernel: [11160.511991] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512026] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512046] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512065] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512084] usb 1-1.5.1: config 1 has no interface number 2
Mar 10 16:02:30 raspberrypi kernel: [11160.524235] usb 1-1.5.1: New USB device found, idVendor=1852, idProduct=50d0
Mar 10 16:02:30 raspberrypi kernel: [11160.524264] usb 1-1.5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 10 16:02:30 raspberrypi kernel: [11160.524283] usb 1-1.5.1: Product: FiiO USB DAC-E17
Mar 10 16:02:30 raspberrypi kernel: [11160.524301] usb 1-1.5.1: Manufacturer: FiiO
Mar 10 16:02:30 raspberrypi kernel: [11160.541054] input: FiiO FiiO USB DAC-E17 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1852:50D0.0012/input/input17
Mar 10 16:02:30 raspberrypi kernel: [11160.541696] hid-generic 0003:1852:50D0.0012: input,hidraw0: USB HID v1.00 Device [FiiO FiiO USB DAC-E17] on usb-bcm2708_usb-1.5.1/input0
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] log.c: Invalid UTF-8 string following below:
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] #004: ▒▒il#006
Mar 10 16:02:35 raspberrypi rsyslogd-2177: imuxsock lost 7948 messages from pid 18986 due to rate-limiting
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error


Well, read errors off of a USB drive.
Still you'd think that MC'd quit trying eventually.

[Hilton]

Well, read errors off of a USB drive.
Still you'd think that MC'd quit trying eventually.

I think I've found the cause of this and it may indeed be a USB bus issue, not a power issue. As I mentioned this occurred on a powered USB hub and I wasn't getting power warnings from the Pi at the time.

I have been running TOP & vmstat and watching CPU/RAM/HDD and interrupt workload and the CPU, RAM and HDD have not hit any bottlenecks, it appears to be a USB bus problem, which I now find after more research, is well known about.

The USB bus in the Pi is a bit funny when you push the USB bandwidth on it because of the high polling interrupts it uses. There's several threads over in the Pi forum about this.

"The Foundation has discovered that the (USB) controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, lost data, etc.."

As anything plugged in uses the USB bus including the onboard Ethernet port you can get into a bit of a problem with real-time audio applications with USB DACs struggling when your using high bitrate content from a USB HDD. This combined with wifi/Ethernet and other USB peripherals plugged in is what caused the crash. Essentially the USB bus crashed because it got flooded. There were thousands of those entries in my log, I just snipped a section of it.

If my understanding is correct, they tried to slow down the USB bus interrupts with some optional cmd switches but it appears that with a high workload on the bus that it may "miss" interrupt requests.
I've been playing with the optional switches to try stop the buffering and will report back what I find.

These are the /boot/cmdline.txt entries Im going to play with. (if you do, backup your SDcard first!)

dwc_otg.speed=0 -> 1 will limit USB speed to full speed 12Mbps (USB 1.1)
dwc_otg.lpm_enable=0 -> 0 by default, it disalbes LPM support - DONT CHANGE THIS
dwc_otg.fiq_fix_enable=1 -> 1 (default now) give about 10% extra performance to ARM Pi B when USB is not busy by lowering the number of interrupts USB does
dwc_otg.microframe_schedule=1 -> 1 (default now) This should fix the error when too many periodic endpoints are present
dwc_otg.nak_holdoff_enable=1 -> 1 (default now) NAK holdoff scheme, This slows down network traffic and smooths the packet delivery so memory doesn't get flooded.


So far turning this off > dwc_otg.fiq_fix_enable -> 0  has reduced buffering pauses on 192k/24bit transcoding to 96/24 but not quite eliminated it.  


There's also some good info in here that I may try out. I had already tried playing with process priorities and not made any progress but there's some ideas in here. http://wiki.linuxaudio.org/wiki/raspberrypi

PS. Im also going to try the latest 3.19 kernel as well.
Someones also compiled a real-time kernel im going to try too.
http://www.emlid.com/raspberry-pi-real-time-kernel/
 

[mwillems]

I think I've found the cause of this and it may indeed be a USB bus issue, not a power issue. As I mentioned this occurred on a powered USB hub and I wasn't getting power warnings from the Pi at the time.

I have been running TOP & vmstat and watching CPU/RAM/HDD and interrupt workload and the CPU, RAM and HDD have not hit any bottlenecks, it appears to be a USB bus problem, which I now find after more research, is well known about.

The USB bus in the Pi is a bit funny when you push the USB bandwidth on it because of the high polling interrupts it uses. There's several threads over in the Pi forum about this.

"The Foundation has discovered that the (USB) controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, lost data, etc.."

As anything plugged in uses the USB bus including the onboard Ethernet port you can get into a bit of a problem with real-time audio applications with USB DACs struggling when your using high bitrate content from a USB HDD. This combined with wifi/Ethernet and other USB peripherals plugged in is what caused the crash. Essentially the USB bus crashed because it got flooded. There were thousands of those entries in my log, I just snipped a section of it.

If my understanding is correct, they tried to slow down the USB bus interrupts with some optional cmd switches but it appears that with a high workload on the bus that it may "miss" interrupt requests.
I've been playing with the optional switches to try stop the buffering and will report back what I find.

These are the /boot/cmdline.txt entries Im going to play with. (if you do, backup your SDcard first!)

dwc_otg.speed -> 1 will limit USB speed to full speed 12Mbps (USB 1.1)
•dwc_otg.lpm_enable -> 0 by default, it disalbes LPM support - DONT CHANGE THIS
dwc_otg.fiq_fix_enable -> 1 (default now) give about 10% extra performance to ARM Pi B when USB is not busy by lowering the number of interrupts USB does
•dwc_otg.microframe_schedule -> 1 (default now) This should fix the error when too many periodic endpoints are present
•dwc_otg.nak_holdoff_enable -> 1 (default now) NAK holdoff schame, don't really know what it does


So far turning this off > dwc_otg.fiq_fix_enable -> 0  has reduced buffering pauses on 192k/24bit transcoding to 96/24 but not quite eliminated it.  


There's also some good info in here that I may try out. I had already tried playing with process priorities and not made any progress but there's some ideas in here. http://wiki.linuxaudio.org/wiki/raspberrypi

PS. Im also going to try the latest 3.19 kernel as well.

 

I haven't been able to reproduce your crash with an external HDD/DAC or with high-bitrate material so far, how many USB peripherals do you have connected?  I want to see if I can replicate.  

The other potential difference is that I'm mostly working with an Arch ARM system.  I'll try and fool around more with my Raspbian image at home and see if I can repro there (if so, then you might be able to side-step the whole issue).  

What kernel are you currently running? 3.18.9 or something older?

[Hilton]

I haven't been able to reproduce your crash with an external HDD/DAC or with high-bitrate material so far, how many USB peripherals do you have connected?  I want to see if I can replicate.  

The other potential difference is that I'm mostly working with an Arch ARM system.  I'll try and fool around more with my Raspbian image at home and see if I can repro there (if so, then you might be able to side-step the whole issue).  

What kernel are you currently running? 3.18.9 or something older?

3.18.7-v7+

Yes Arch might side step the issue.

[mwillems]

Ok, I'm on 3.18.9-1 FWIW.  I just checked my logs and dmesg on the Arch system, and saw no i/o or ntfs errors (I'm also using an NTFS formatted drive).

NTFS may be part of the picture too.  Linux's NTFS implementation has improved pretty dramatically over the past few years, so it may be that the older NTFS implementation in wheezy (from 2012) may be partly to blame.  

I'll see if I can get mine to wig out on Raspbian.  

[Hilton]

Ok, I'm on 3.18.9-1 FWIW.  I just checked my logs and dmesg on the Arch system, and saw no i/o or ntfs errors (I'm also using an NTFS formatted drive).

NTFS may be part of the picture too.  Linux's NTFS implementation has improved pretty dramatically over the past few years, so it may be that the older NTFS implementation in wheezy (from 2012) may be partly to blame.  

I'll see if I can get mine to wig out on Raspbian.  

Im updating to 3.18.9 now and see if its any better before I do anything else.

[Hilton]

Im updating to 3.18.9 now and see if its any better before I do anything else.

On
Linux raspberrypi 3.18.9-v7+ #767 SMP PREEMPT Sat Mar 7 21:52:35 GMT 2015 armv7l GNU/Linux

[  145.084381] Transfer to device 6 endpoint 0x1 frame 1029 failed - FIQ reported NYET. Data may have been lost.
[  428.986297] Transfer to device 6 endpoint 0x1 frame 221 failed - FIQ reported NYET. Data may have been lost.
[  497.515425] Transfer to device 11 endpoint 0x1 frame 1157 failed - FIQ reported NYET. Data may have been lost.

Get these when it buffers now but I haven't changed cmdline.txt back to defaults yet.

PS. Just HDD, Key/mouse, wifi, DAC with Key/mouse on powered Hub.

[mwillems]

Have you tried looking at iotop and iftop (or similar utilities) to see if the errors correspond to particularly high disk or net traffic periods or if there's some other driver?  

It would be good to know exactly how much bandwidth causes the issue.

[Hilton]

Have you tried looking at iotop and iftop (or similar utilities) to see if the errors correspond to particularly high disk or net traffic periods or if there's some other driver?  

It would be good to know exactly how much bandwidth causes the issue.

Just trying something I should have tried earlier... a different USB HDD to see if its the Toshiba Canvio slim II that's the problem. Its new so I wouldn't expect it to have problems but here goes!

[Hilton]

Just trying something I should have tried earlier... a different USB HDD to see if its the Toshiba Canvio slim II that's the problem. Its new so I wouldn't expect it to have problems but here goes!

Doh. The Toshiba is at fault. An old Seagate 500Mb doesn't buffer at all even at the beginning of tracks with 192/24.  edit: or even skipping tracks, no gaps or buffering just straight to the next track.
Must be something to do with Toshiba firmware.  Burst buffer must be better on the Seagate too or something, because in hdparm tests they both get identical direct disk read performance.

[Hilton]

Seagate supports DMA6 Tosh only DMA5.

Code: [Select]

pi@raspberrypi ~ $ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       ST9500325AS
        Serial Number:      5VE928EE
        Firmware Revision:  0002BSM1
        Transport:          Serial
Standards:
        Used: unknown (minor revision code 0x0029)
        Supported: 8 7 6 5
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  976773168
        Logical/Physical Sector size:           512 bytes
        device size with M = 1024*1024:      476940 MBytes
        device size with M = 1000*1000:      500107 MBytes (500 GB)
        cache/buffer size  = 8192 KBytes
        Nominal Media Rotation Rate: 5400
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 128
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
                Device-initiated interface power management
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Long Sector Access (AC1)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
                unknown 206[12] (vendor specific)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        136min for SECURITY ERASE UNIT. 136min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c50021719efb
        NAA             : 5
        IEEE OUI        : 000c50
        Unique ID       : 021719efb
Checksum: correct


Code: [Select]

pi@raspberrypi ~ $ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       TOSHIBA MQ01UBD100
        Serial Number:      Z48DTM19T
        Firmware Revision:  AX101U
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
        Supported: 8 7 6 5
        Likely used: 8
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors: 1953525168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      953869 MBytes
        device size with M = 1000*1000:     1000204 MBytes (1000 GB)
        cache/buffer size  = 8192 KBytes
        Form Factor: 2.5 inch
        Nominal Media Rotation Rate: 5400
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 128
        DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
           *    Advanced Power Management feature set
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
           *    IDLE_IMMEDIATE with UNLOAD
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    Idle-Unload when NCQ is active
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT LBA Segment Access (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        244min for SECURITY ERASE UNIT. 244min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 0000000000000000
        NAA             : 0
        IEEE OUI        : 000000
        Unique ID       : 000000000
Checksum: correct

[JimH]

Is one of the drives USB 3.0 compatible and the other one only USB 2.0?  If so, the difference may still be power.  The USB 3.0 drive draws a little more power.

[Hilton]

Is one of the drives USB 3.0 compatible and the other one only USB 2.0?  If so, the difference may still be power.  The USB 3.0 drive draws a little more power.

They are both USB 3 but the Seagate is only Sata I 1.5G sig spec where as the Tosh is Sata I 1.5 and sata II 3G sig spec, so it's probably got to do with the Toshiba implementation of their Sata II to USB bridge.

[mwillems]

My USB HDD (which works correctly) is a USB3, Western Digital SATA II.  So it looks like something specific to the Toshi implementation.

[phil57]

Hello JRiver MC Team,

I use a Synology DS214se (NAS) with the CPU Marvell Armada 370 based on armv7 architecture.

Did you plan to compile the JRiver Media Center demo 20.0.81 as a synology SPK package for the models with armv7 CPU ?

Thanks in advance for your reply.

[JimH]

Not any time soon.

[phil57]

Thanks for your reply.

[hvoerman]

Hello great MC Team,

I just want to let you know that I'm using MC20 for ARM (Raspian on RPI2) right from the start and I am really enjoying it. I hope you will decide to continue support for ARM/RPI(2) Perhaps even an RPI2 optimised version?

Many thanks,

Hugo

[desa]

I'm getting a strange behavior with gapless playback.

It looks like the new track playback is started before the old track finishes so you have a few seconds overlapping between the two tracks. It is like fading is applied to the transition.

I'm not 100% sure, but it looks  specific to the ARM version as I've not been able to recreate the same issue with the x86 Linux version. I'm not 100% sure because the ARM version is 20.0.81 while the x86 version is 20.0.84, so it may be specific to the 20.0.81 version, as well.

I've tried several settings, but nothing changed.

I'm using a Cubox-4i Pro with Wheezy (armhl) and kernel 3.14.14. I usually run MC as a renderer with the /mediaserver switch and the dummy xorg driver, but I also tried to run it interactively on a vncserver (tightvnc).

Did anybody experience the same issue?

Thank you

[bob]

I'm getting a strange behavior with gapless playback.

It looks like the new track playback is started before the old track finishes so you have a few seconds overlapping between the two tracks. It is like fading is applied to the transition.

I'm not 100% sure, but it looks  specific to the ARM version as I've not been able to recreate the same issue with the x86 Linux version. I'm not 100% sure because the ARM version is 20.0.81 while the x86 version is 20.0.84, so it may be specific to the 20.0.81 version, as well.

I've tried several settings, but nothing changed.

I'm using a Cubox-4i Pro with Wheezy (armhl) and kernel 3.14.14. I usually run MC as a renderer with the /mediaserver switch and the dummy xorg driver, but I also tried to run it interactively on a vncserver (tightvnc).

Did anybody experience the same issue?

Thank you

Maybe not enough horsepower for the transition.
Try turning it off.
Options->Audio->Track Change.
Make it gapless and turn off the "do not play silence" option.

[bob]

Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.

Thanks.

[mwillems]

Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.

Thanks.

I just tried it on a Pi 1 B+ and after a few clicks got

Code: [Select]

Illegal Instruction (core dumped)

So it's not just your Pi, unfortunately.

[Hilton]

Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.

Thanks.

20.0.91 running fine on Pi2B so far for 20mins. Have logging turned on, if I get a crash I'll provide the log.
I'll restart with the new /mediaserver switch.

[mwillems]

I should add I've also had no problems on my Pi 2's

[Hilton]

No problems for the last half hour in /mediaserver mode running mixed mp3/FLAC and loading different playlists or searches from JRemote on the Pi2B.

[bob]

I don't have any trouble on the RPi 2 either.

I don't know how any illegal instructions could have entered the equation.

Unfortunately I can't get eclipse to work properly on the RPi 1, probably not enough memory and command line gdb shows the crash in a system lib :-(

[Mark_NL]

Still got the same troubles : stutters at the end of a song;

http://yabb.jriver.com/interact/index.php?topic=96616.0

Does anyone of you use a USB2 (uac2) dac?

[bob]

Still got the same troubles : stutters at the end of a song;

http://yabb.jriver.com/interact/index.php?topic=96616.0

Does anyone of you use a USB2 (uac2) dac?

I use a Dragonfly without issue.