#81

@frankchannel had experienced the xruns so I don’t know specifically which scripts. Perhaps he can chime in?

I did have another thought - is it possible the difference in Codec performance could account for this? Either that or you’re doing something slightly different in the monome kernel as opposed to the stock Buster-lite image I’ve started from.

#82

There were no specific scripts that caused me any problems, however, about 50% of the time I would see the message "error: SUPERCOLLIDER FAIL" on the norns screen after rebooting the pi.

Looking at the journalctl log jack_wait complains a few times, but
eventually jack starts. The real problem seems to start a bit later and is indicated by these lines:

Aug 07 20:31:58 norns crone[419]: setting up jack clients..
Aug 07 20:31:58 norns crone[419]: starting jack clients..
Aug 07 20:32:01 norns jackd[318]: JackEngine::XRun: client = softcut was not finished, state = Triggered
Aug 07 20:32:01 norns jackd[318]: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Aug 07 20:32:01 norns jackd[318]: JackEngine::XRun: client = softcut was not finished, state = Triggered
Aug 07 20:32:01 norns jackd[318]: JackAudioDriver::ProcessGraphAsyncMaster: Process error
Aug 07 20:32:43 norns jackd[318]: JackEngine::XRun: client = SuperCollider was not finished, state = Triggered
Aug 07 20:32:43 norns jackd[318]: JackAudioDriver::ProcessGraphAsyncMaster: Process error

I tried changing jack’s buffer size from 128 to 256 and that seemed to fix it. I’m really not sure what was going on though.

#83

well… it of course makes sense that increasing bufsize in general will increase CPU usage

in softcut, as in many SC bits, expensive computations are placed in the top of each audio block, moving them out of sample loops whenever possible.

just, weird that the systems behave differently. i am not sure about kernel-level changes. systemd-level changes include masking out raspi-config in the setup script, which could affect governor settings… i dunno.

hm… if jack is just taking a long time to boot and sometimes missing the timeout deadline, maybe just increase the timeout time here

2 Likes
#84

I’d love to get a little more detail about that “masking out” (I don’t really understand what that means here). Could you PM me as not to clog up this thread with minutiae? (my setup sets governor to “performance” if i recall correctly)

#85

minutiae

just, in systemd:
“stop” means stop
“disable” means, “stop and don’t run this service at boot, unless another service asks for it”
“mask” means, “completely remove the link to this service, so it cannot be run at all”

i dunno, just noticed this line in the norns setup script. i’m not familiar with details of reasoning but @simonvanderveldt probably is.
https://github.com/monome/norns-image/blob/master/setup.sh#L93-L95

if you’re using “performance” then i guess that’s probably unrelated to the apparently lower CPU headroom available to jack client callbacks. unless “performance” causes thermal issues and throttling down the road, or something.

3 Likes
#86

Never wrote in this topic but I am super interested in the shield.
So if there is a waiting list, add me to it.
If not I am monitoring the topic
Thanks for doing this and giving the opportunity to people to play with the Norns ecosystem

3 Likes
#87

I know theres been some talk about adding i2c functionality, but it would not make sense on norns as it does not have a i2c port, but maaaaaybe an i2c port on the norns diy shield could make sense, and in extension adding i2c to the norns software suite.

:upside_down_face:

#88

I could be wrong, but I believe “the way forward” for i2c on norns is crow.

I looked into adding this for my fates board, but it’s not directly supported in the norns software stack and would require a bunch of coding and specific script implementations that would not be portable to the original norns hardware.

1 Like
#89

yeah, was thinking the same, but crows does way to much and seems so unnecessary if i just want to send i2c messages to my er-301. was thinking about getting a crows or a 16n to sit between the 301 and the midi world. that would make my (soon to come) setup to look like this: Sequncer–> norns–> crows–> er-301

with the 301 already suffering from a bit of latency, it does not feel optimal.

#90

in a good way!

To me.

just in case, hehe. I actually really want a crows, but cant justify it right know

#91

16n could act as an i2c translator for you (taking usbmidi from norns and spitting out i2c).

norns -> 16n -> ER-301

#92

yes.

still, getting any of those are a bit to much just to send i2c to the 301.

But maybe it would feel unfair to the ones who got an prebuilt norns to add i2c to the diy version, forcing the ones who paid the most to pay even more for i2c

#93

I wouldn’t write off implementing i2c communication as a trivial or simple task. You’re probably unlikely to get a diy norns only function developed unless you pick it up yourself.

On the other hand, there are some folks actively working on getting communication set up between crow and the er-301. As far as latency goes, I’m not sure that would be an issue to worry about at this point (we will know soon enough).

1 Like
#94

ye, it seems very hard from my perspective. But i want to push a “less adapters” philosophy

#95

i would advocate for the creation/use of a very tiny/simple usb-i2c converter, so it could be used with any usb host (ie even computers with macos/etc)

in fact, there’s probably a linux driver for this: https://www.adafruit.com/product/2264

add a 3.5mm stereo jack— and then some matron/lua code.

7 Likes
Aleph ii / i2c Dev
#96

There is indeed. I don’t know enough to say more, but “Virtual Com Port” drivers appear to be already in the kernel (“All FTDI devices now supported in Ubuntu 11.10, kernel 3.0.0-19”).

#97

rad.

one advantage of this is being able to use a long USB cable which has “balanced” data lines, so “immune” to noise, whereas the i2c cable length should be kept very short. (quotes because this is a semi-accurate simplification)

1 Like
#98

This issue should also be resolved.
Sounds like a great idea!

#99

I wouldn’t assume they use the same driver, would be good to check device IDs.

Also it seems there’s a USB to header stick from FTDI themselves called C232HM (but 3,5mm is a bit nicer)

#100

Yeah, and D2XX drivers are also available for Linux if you want to go that way.