Latest Pianoteq with Oram

Hi @le51 :slightly_smiling_face:

I have an Rpi5+Nvme kit + external Presonus USB audio, waiting to be put to the test with Oram, and will let know to the @Zyntianers how it performs headless on this setup, as soon as I find a bit of time for music IT experimentation, in this busy period for me.

My first port of call will be, of course, to verify the correct Zynthian/Oram startup from an internal Solid State Drive with Rpi5.

More to follow: I will keep you updated!

2 Likes

:+1:

1 Like

Thatā€˜s great work @jofemodo much simpler to optimise or Pianoteq settings. Could I ask to your pi5 test, what was your buffer size on Jack (please say 128bit), also assume 2 buffers and not 3.

I always use the default config from ZynthianOS: n=2, p=256, f=44100 (11,6 ms latency)

I will repeat with 128 and will report in this thread.

Thanks

1 Like

Please also try 48000. I would like is to move to 48000 as standard. It has a few advantages including:

  • Some soundcards have native 48000 samplerate so work better
  • It allows us to enable jamulus integration
  • Slightly reduced latency
  • it is an industry standard so can help with interfacing and data exchange

44100 was a bodge done to allow CDs to be made from the different refresh rates used around the world but should be assigned to the dustbin of history.

4 Likes

Well, iā€™m almost convinced to increase the ā€œdefaultā€ sample rate in Oram to 48000.

Indeed, i was testing the Pi5 with 2 buffers of 128 samples, what reduces latency to 5 ms:

-r 48000 -p 128 -n 2

I tried to generate XRuns by running Pianoteq with ā€œGrand Ant. Petrofā€ model, with 128 voices of polyphony at full sample rate (internal sample rate = jackd sample rate) and no CPU overload detection.

I couldnā€™t, although i pressed the sustain pedal while playing all notes in the keyboard in the more brutal way i could! The Pi5 is a total killer, mates!! :star_struck:

Cheers!

4 Likes

Thanks jofemodo for your testing, I really appreciate it. pi5 looks exactly the right spec for Pianoteq, I was worried it would just fall short :sweat_smile: Iā€™ll put pi5 on my birthday present list

1 Like

Guys, I just installed Oram test version and for the love of God I cant find Pianoteq anywhere. Is it under the Instrument chain somewhere? Also I cant locate SFZ. In the WebUI I see them all under Software-Engines as Enabled.

Instruments are now separated into categories. You must use one of the encoders or left/right buttons to change to the Pianos category.

1 Like

Thanks a lot, I read it in manual few moments ago. Problem is that I dont have a kit, just the Pi and DAC+. I tried the touch, but it does not work reliably. I used keyboard and it works fine.

Yeah and after 33rd restart touch now works as well. Dah

Iā€™m having a little trouble with pianoteq stage 8.2.2 (licensed version) in oram.
Iā€™m using a pi4b, with and old apogee duet as the USB audio interface.
It worked well using the stable build, with oram it either doesnā€™t load (no sounds on pianoteq chain after boot), or locks up after a bit.
My audio driver settings:

-P 70 -s -S -d alsa -d hw:USB -r 48000 -p 256 -n 2 -X raw

If I change the cache to 512 it seems to work, but feels like a bit more latency.

Like I said, worked fine in stable build. I can provide logs if thatā€™s helpful, just donā€™t know which ones or where they areā€¦

The apogee may be just too old too, if yā€™all think thatā€™s the case then thatā€™s ok (itā€™s pretty old)

If the hw:USB is choosing the first USB device as Zynthianā€™s sound-card you might get inconsistent results depending on what the system finds at each boot.

You can do an amidi -l command to ask ALSA to display the USB device names on your system, and then specify apogee duetā€™s name specifically.

Thanks @tunagenes, the Duet actually identifies as ā€œUSBā€ though:

(venv) root@zynthian:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 3: USB [Duet USB], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice

Wow, Interesting. I wondered if it could be the duetā€™s name but it seemed like a crazy idea - what if every device had USB as a name!

1 Like

Itā€™s pretty pretentious of Apogee.

I switched out the duet for a Zoom ams24 Iā€™ve been using for something else and the problems went away - so the Apogee and its haughty identifier will be relegated to a menial task.

1 Like

Hi @jofemodo, @le51 and @zynthianers,

I can confirm that on Pi5+nvme+Oram I can run pianoteq at full sample rate with 128 voices, as conveniently implemented by Fernando in the pianoteq webconf page, without any xruns or artifacts of sort.

Just a couple of questions and a possible Oram issue report:

  • Is ā€œfull sample rateā€ in the pianoteq config tab the 48 Khz of my audio board settings? (I am on a Stage license, thus 48K is the ceiling)

  • I noticed that the metal enclosure of my Pi5, with both active and passive cooling, becomes significantly hot during ordinary Oram operation. Would it make any sense to attempt a bit of overclocking (possibly somewhere in the webconf options?) or would it put the CPU under unnecessary thermal stress, with a neglectable increase in performance?

  • The damper pedal CC switch, received through a midi controller hooked directly to a Pi5 USB-A port, seems to occasionally remain stuck in pedal-down position (not the behaviour the same pedal and controller show with my other gear). The passing malfunction happens only with Pianoteq with some amount of built-in convolution reverb.

Edit: the stuck damper pedal CC issue in Pianoteq does not seem to happen if Midi is received through 5-DIN connectors.

2 Likes