Thanks for the update Jeremy but according to a user on jack-devel, JACK is having probs running on the BBB too.
I may try J1 on my Pandaboard too but it'd be just out of curiosity to see if it does work. The lack of ARM/NEON optimization in the LA stack currently means I can't realistically use the Panda for what I like to do with Linux audio. Wheezy is otherwise rock solid on it. I had to power it down yesterday when we were doing some work on the house and it had an uptime of 18.5 days. No great feat but I'm sure it would've been up for much longer if given the chance.
If I was real gung-ho about JACK on ARM I'd prob consider one of the Chromebooks - gone are the days when dev boards are the only option for those wanting a modern ARM Linux machine.
On Fri, Jun 28, 2013 at 2:52 PM, Jeremy Jongepier <jeremy@xxxxxxxxxxxxxx> wrote:
On 06/19/2013 03:39 PM, Jeremy Jongepier wrote:Just an update. Getting things stable is quite some work actually but I'm slowly getting there. I've stripped the kernel config a bit further and have a good starting point now. Some findings:
On 06/19/2013 12:08 AM, Dan MacDonald wrote:
That's what I expected, seeing how little success I've had on my
Pandaboard
with J2 git. Have you tried J1 too?
Ok, got Jack1 running. Recompiled the kernel without debugging and
disabled WiFi. I now see I can also tweak the IRQ threads, nice.
Jeremy
* RT patch doesn't apply cleanly. I've hacked my way through it but can't get it to compile.
* I've tried using threadirqs but then the stick wouldn't boot (couldn't find any rootfs to load from MMC). Applied this patch: http://www.spinics.net/lists/linux-rt-users/msg08062.html
Then I get threaded IRQs but it's not much of an improvement, the USB IRQ that has the WiFi connected to it consumes a lot of CPU and I can't get JACK to run stable. I did try prioritizing IRQs with rtirq but it didn't make any difference, the board seems to run better without threaded IRQs.
* Tried dwc_otg.speed=1 as a kernel parameter, no improvement.
* This thing doesn't have serial console access, I've tried all possible pads, vias and pins but no joy :( I did manage to solder a button on the board that allows me to directly boot into flash mode which is already quite convenient.
* No ethernet access, only WiFi. But enabling WiFi means JACK won't run properly. Also tried an external USB dongle, same problems basically.
* So I have to work using the HDMI connection and a keyboard. Had to disable blanking otherwise JACK would crash.
Well, that last example sums it all up I guess, this board isn't really made for doing real-time audio. Unless people prove me wrong, I'd love to hear what other people's experiences are. Any tips, ideas, suggestions? I'm now glazing at amsynth 1.4.0 running headless while JACK occasionally spits out 'delay of .... usecs exceeds estimated spare time of .....; restart ...' messages and that with jackd -P84 -p32 -t2000 -dalsa -n3 -p128 -s
I HAVE to use the ALSA -s (softmode) option otherwise the whole USB stack locks up. Pffff, maybe I should buy a board that does work, like the pcDuino or BeagleBone Black.
Regards,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
