Chromebook + Pianoteq (Page 1 of 2)

What is the basis of your measurement that Pianoteq runs  75% faster on the Chromebook?  CPU load 1/4 of non-Chromebook?  The best measure would be the DSP load reported by Jack for the same latency settings.,

The way I measured was with offline generation of a 100+ polyphony midi file.  (See the benchmark thread.)  I will say I was comparing 2 different distros.  My Linux distro preference is Fedora 20 so I'll have to download the Ubuntu LiveCD to have a true apples-to-apples comparison.

As for whether a Celeron performs well or not, you have to remember that Intel's naming schemes are meaningless.  You cannot assume that a I3 will automatically outperform a Celeron.  Instead, look at architecture, cores, clock speed.  A Celeron 2995U is a Haswell dual core 1.4ghz CPU.  A Haswell I3 would be roughly the same thing but with hyperthreading (2 more quasi-cores).  I5 has 4 cores, I7 has 4 cores + hyperthreading.  Since Pianoteq only can use 2 cores max, a Haswell I3/I5/I7 1.4ghz would run no faster than a Haswell Celeron 1.4ghz.  Then you need to add like 15% or so to each generation -- a Haswell 1.4ghz runs about the same speed as a Ivy Bridge 1.8ghz (temporarily had this laptop).

And from my quick experience, this Chromebook w/ Celeron 2995U can do 100+ polyphony at 48khz with no problems.

Celeron 2995U is a dual core CPU -- no hyperthreading.  On both Acer E1-432 running Fedora 20 x86 and Chromebook C720P, both coress are pegged at 100% the entire time.

Again, it's different Linux versions.  ChromeOS uses a way newer Linux kernel than Fedora.  There may be other software stack factors but I'm using a Mate-desktop LiveUSB to do an "out of the box" test.  What this does mean is if it's a software issue, ChromeOS obviously has figured out how to optimize for performance & power.  (Another comparison -- Acer E1-432 lasts 4 hours running Fedora, Chromebook lasts 9 hours.)

I'm right now downloading Ubuntu 14.04 to test that on a LiveUSB.  If I could rip the hard drive out of the E1, I would even test ChromeOS on it w/ the same Crouton config.  Unfortunately, when I opened up the laptop, the hard drive was hidden underneath the motherboard.

At first, very interesting project to use a chromebook/chromeOS as host for a linux/pianoteq guest system! Thanks Mossy!
When chromebooks go under 200 EUR I probably will try that.

Just for interest, is the "limitation" to 2 cores verified somewhere? Until today I thought all cores are used.

cheers

Here's my 4-core I5:

> more /proc/cpuinfo | grep MHz
cpu MHz: 1199.000
cpu MHz: 1199.000
cpu MHz: 1199.000
cpu MHz        : 1199.000

Run command to render MIDI to WAV using Pianoteq ... then while it was render, run the following commands:

> more /proc/cpuinfo | grep MHz
cpu MHz: 2267.000
cpu MHz: 1199.000
cpu MHz: 2267.000
cpu MHz: 1199.000

> dstat 15
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
20   5  73   1   1   0|1109B 2190B|   0     0 |   0     0 | 247   700   <-- ignore this line, this is since bootup
47   3  48   1   1   0| 273B   21k| 415B  704B|   0     0 |3539  3608
46   3  49   0   1   0|   0  3277B| 435B  669B|   0     0 |3363  3770

These 2 data points -- ~50% idle plus only 2 cores bumped up to max speed -- tell me only 2 cores were being used.  (And no, Intel does not allow you to set CPUFREQ separately per core -- AMD used to let you on their Phenom 2 CPUs but not anymore either.)

As for the 75% difference in performance, I think there is something weird about Fedora.  I just tried the following on several different laptops using a Fedora LiveUSB:

"Pianoteq command to render midi -> wav"
--> 16sec
sudo "Pianoteq command to render midi -> wav"
--> 40sec

For some reason, elevating rights to root access slows Pianoteq down by 150%

By comparison, an admin account on Chromebook is about 15% slower than a regular user account.  (Again, I'm STILLLLL downloading the Ubuntu distro ... ugh.)

So Pianoteq definitely does not like priviledged accounts but what Fedora is doing is pretty wacky.  There may be config options but this is deep into the rabbit hole -- I doubt Google will give any answers for this.

Would you mind sharing which i5 model, exactly? Many i5 are actually two-core CPUs with hyperthreading (mine is too, for example), which means that you will always see virtual 'pairs' of cores. Apart from that the fact that not both cores run on maximum speed tells us nothing, as Pianoteq cannot instruct the operating system to just run stuff on specific cores.

What the software can do and usually does is launch so-called 'threads', which are more or less light-weight processes, and the operating system will then decide what CPU they will run on. If for whatever reason it thinks it more efficient, it might even run all threads on a single core and send the others to sleep (my phone does this, for example: very often 3 of its 4 cores are completely idle and sent to sleep).

So what happens is this: Pianoteq detects 4 native processor threads, with no information if those correspond to real cores or hyperthreading (i.e., 'virtual') cores. It therefore starts 4 worker threads to do its calculations. This enables the operating system to split the work between a maximum of four cores: but there is absolutely no guarantee that this will actually happen. Especially in the case of writing a WAV you might also hit a bandwidth limitation.

The reason for you seeing only 50 percent load when exporting a WAV might actually be bandwidth, together with hyperthreading. It is almost exactly the same on my hardware here: I get around 75% system load when Pianoteq runs in realtime with 256 simultanous notes. Two hardware cores show a completely maxed-out state, while the two 'virtual' (HT) cores are running at about 50%. This is to be expected, since those two CPU 'cores' are actually simulated to make use of the 'leftovers', but there is a limited amount of those.

Very roughly speaking, HT makes use of the fact that not all commands you run on a CPU core actually do use all of its circuits. There are commands that are simpler than others, and leave maybe up to 50% of the CPU core unused. This is where HT comes in: it creates a second, virtual core in order to maximise the hardware usage. However, this is not a magic bullet.

Now, when I export a WAV, the system load actually drops significantly to almost precisely 50%, with two cores still maxed out, but the two others seemingly doing nothing. But what should not be forgotten is that Pianoteq runs at about 8-10x realtime speed for a normal MIDI file, which increases the memory and storage/IO bandwidth it uses. Intel state themselves in their hyperthreading docs that bandwidth limitations can even degrade performance under certain circumstances, or completely eliminate the gains of HT in others.

(I would like to see an example on an i7 CPU. Those are almost always 'real' quad-core processors. Some i5 are too, but only some desktop series. Mobile i5 usually are 2+2.)

Mossy, will your Chromebook use a regular generic USB audio and midi drivers?  I would use this with my M-Audio Sono-88 which has generic midi and audio interfaces built in.  I like this because it was cheap, light, has an 88 note semi weighted keyboard, and one USB connection gives me both midi and audio.  It also lets me mix in a second stereo audio source which I use for my second keyboard, and has two headphone jacks in the front.  If that would work together and let me stretch out a little on piano at a low latency, it might be exactly what I need.

Second question: is there some sort of generic ASIO driver like ASIO4ALL for Linux that would work with this Crouton version?

Not more, than an idea:
Members of the group 'audio' often have a higher realtime-prio, set  in /etc/security/limits.conf or similar:
[...]
@audio - rtprio 90
@audio - nice -10
@audio - memlock 500000
[...]

The "superuser" root is not a member of group audio.

It might also be the result of over-locking. A file being generated is essentially a 'serial' ressource. Especially when considering effects like reverb, you just have to write it from beginning to end. When creating a ZIP archive, for example, you can achieve independent blocks, but I guess in the case of an audio file this is going to be virtually impossible.

In 'real time' mode the sound device is written to rather slowly, so it is not an issue. But when writing audio to a file as fast as possible, the file becomes a bottleneck. Depending on how the implementation works exactly, it might be that more or less one main thread ends up doing most of the work because it is the one responsible for writing the results. Access to shared ressources is one of the main reasons parallelism is hard and the gains are most often not linear with CPU cores.

Edit: this seems to be indeed the cause. I just created a MIDI file with maxed-out polyphony (200~250 concurrent notes, permanently). When I export this to a WAV, I indeed see a much higher load on my system, about 75%, which sounds about right considering two of my "four" cores are just hyper threading abstractions. When polyphony is lower, the load drops since the work can be split only so much and a lot of time is spent just waiting for the output. It is probably possible to improve Pianoteq's parallelism, but I speak from experience when I say that this is often easier said than done. As I said, parallelism is hard.

Erm... I'm reasonably sure that pstree does not show individual threads, by the way. Threads are considered part of one process. (I.e., child processes and threads are separate concepts.)

As I said: processes and threads are different things. Threads usually do not show up in the system process list as separate entities: forked child processes do, of course, but they are not the same thing. I don't have the time currently, but I should perhaps just write a small threaded C++ program on my Linux box, let it start about 30 threads and look at pstree. My current guess is still very much that they won't show up. It is difficult to impossible to see the running threads of a program without debugger.

I just did a small test. It actually does seem that Linux assigns a kernel process ID for each kernel thread it runs. I wrote a small Python program that did not much more than start 10 worker threads, and I could indeed see the complete structure with pstree. So it really seems to be able to show at least all 'real' kernel threads, and those are the ones that are important.

Anyone from Modartt care to shed some light on Pianoteq's multi-core capabilities?

I think what's meant there is threads in the operating system domain vs. threads in the domain of 'normal' software. The language regarding threads and processes it at the very least not very precise...

Anyway, what I meant was that there are in theory two mechanisms of creating threads. One is internal to the program and does not help you utilising multiple CPU cores. On the other hand, it is a valid tool to model certain problems and works even if the operating system is not multitasking-capable. The other is what I called a 'kernel' thread, one could also say a 'native' thread... that is, a thread the operating system creates for the program and therefore knows about. This enables the Linux kernel to balance those threads between different cores.

Yes, that's more or less the exact definition of how it works on a multi-tasking operating system with native threads, i.e., all modern systems. Threads are logical units, a modelling tool in solving a problem... and they can be used to improve efficiency. Which is why the software uses the operating system to create them nowadays. How they are run and on which core is up to the OS kernel, of course.

The offered threads from Pianoteq seem to be independent from the number of cpu-cores. Regular playing on a connected midi-keyboard opens 5 threads on Mossy's dual-core 2955U, on my older dual-core T7300 I just tested and on my quad-core N2930.

Mossy, one question to your "crouton guest linux".  What type of soundsystem is detected and used by Pianoteq in your guest chroot? ALSA, JACK, Pulseaudio, ...?

Hi,

I have a fanless Acer Chromebook cb3-111 now (219 EUR), but my first results with Chrome OS as host for a guest-linux are not so great.

I followed your hints and hotfixes and installed the default Ubuntu LTE guest with Xfce4 Desktop. The Pianoteq5-Demoversion shows two Outputs:

1.) Default ALSA Output (currently Chromium OS Audio Server)
2.) Chromium OS Audio Server

With 48000 Hz Sample rate my smallest Audio buffer is 192 samples (4.0 ms). The cpu-freq I maxed to 2.16GHz with governor performance (in the guest):

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

With just these settings Pianoteq's Perfomance Index is 22 in the guest.

But the other side of the medal: The output is sluggish and definitely more than 4ms. No fun to play.

Your idea seems to be good to circumvent CRAS and directly connect to ALSA.

Do you have acceptable latency on your Chromebook C720p?

cheers

Thank you! I will try that.

I put the modprobe command inside /usr/local/bin/startunity.

I tried to hack a script to launch Pianoteq without Unity or XFCE but I'm not sure what display server is needed to make this work.  (You can start XBMC directly from ChromeOS but XBMC has a "no Linux desktop" mode.)

EDIT: Pianoteq launches but there is no mouse support (X-Server probably needed) so you can't choose anything.

EDIT 2: Works in headless mode once Pianoteq has been configured once in Unity.  I did the following:

  sudo modprobe snd-seq-midi
  sudo enter-chroot
  /opt/Pianoteq/amd/Pianoteq\ 5 --headless

EDIT 3: Works using Chrome's X Server but mouse pointer does not display.  You have to guess where you roughly are.  Unfortunately, it does not support my Chromebook's touchscreen capabilities.

  sudo modprobe snd-seq-midi
  sudo enter-chroot
  host-x11 /opt/Pianoteq/amd/Pianoteq\ 5

Automated it with:

* Crosh shell
  * enter-chroot
    * create /usr/local/bin/startptq
       * sudo -u USER host-x11 /opt/Pianoteq/amd/Pianoteq\ 5

* Crosh shell
  * create /usr/local/bin/startptq
    * modprobe snd-seq-midi
    * chmod 777 /dev/snd/seq
    * /usr/local/bin/enter-chroot -x "/usr/local/bin/startpq"

So now to start up, my routine is:

* Crosh Shell
  * shell
  * sudo startptq

The only issue is the mouse pointer not showing up which I can semi-live with.

Using whatever Google sends me via their  updates.  I randomly use the term Chromium vs Chrome nowadays because I've been browsing the developer forums to read up on it.

As to why start up Pianoteq directly, before I got my Chromebook, I read up on all the various Linux options thinking I would need them to do my work.  So the first thing I did was switch on developer mode and install Crouton+Ubuntu+XBMC+cli tools -- and never used any of it for the 2 weeks I was on travel.

(I do use Crouton+XBMC now for my kids to pick videos to play.)

So it's inefficient to startup a complete Unity desktop just to launch Pianoteq when there's nothing else in there I use.  I'd rather have it open under the main Chrome UI where I have access to the rest of my tools.  The missing mouse pointer is irritating but because Pianoteq changes the highlight when you hover over elements, it's not that hard to guess where you are.

Ok, followed your hints but instead of using crouton to install another target, I just did:

host-x11 openbox &
host-x11 (pianoteq command)

Mouse works, touchpad works -- touchscreen does not.  (Touchscreen doesn't work under XBMC either but does work under Unity so I suspect not all window managers support it.)

Some weird stuff happens when you drag the window and if you minimize/click away, it seems to disappear but you can alt-tab back to it.

I may try a few other window managers to see what plays better with Chrome's touchscreen.

I tested a bunch of other window managers (compiz, metacity, mutter and a few others) .. and it looks like they act a bit funny if you've previously run one and didn't reboot before trying another.  After rebooting before testing, openbox didn't have the same weirdness (which probably means running unity/xbmc leaves some weird bits flipped on in ChromeOS's X server).

Mutter seems to work the best but if you bring it to the foreground to kill it -- it just turns your computer off.  It's fine if you just leave the chroot and let the system auto-kill it.

And from what I can tell, touchscreen actions are being captured by Chrome's X server but none of the underlying window managers know what to do with it.  When I first start up Pianoteq, tap-to-click on the touchpad works perfect.  But the moment I touch the screen, tap-to-click is disabled and I have to press down on the mouse buttons first.  What this implies is the window manager received a touch signal that looked like "hold-down" and it's up to the desktop (Unity,Gnome3,etc) to interpret what to do.

It was interesting to me, how differently two similar netbooks can sound depending on their hardware. I compared my Acer Chromebook CB3-111 with a standard Acer Notebook E3-111. While the Chromebook has a new soundchip 'byt-max98090', I have never seen before , the E3-111 has a more common chip 'ALC 283'. Both sound differently to me.

Without measuring the headphones-outputs, a lot of reasons are possible. The ALC Output seems to have a slight roll-off in the bass and an overall leaner/thinner sound.

The byt-max has more mids and lower mids and a more real piano balance.  At the same time it is a bit clearer and transparent to my ears.

I like the sound-characteristics of both laptops and I'm sure, the differences could be easily measured (output-impedance, EQ). The byt-max98090 seems to be the more professional one, because it has many, many mixer items. For the moment I just wanted to share, that there are differences.

ciao

PS: Compared with the same 32 Ohm headphones Beyerdynamic DT 235.

Here's the downside to using a Chromebook.

My wife powered the machine on, was puzzled by the initial screen warning that developer mode was one ... and pressed space which blew away the entire install.  (The message says press space to disable developer mode.)  The Google/ChromeOS stuff ... easy, log back in, sync and everything is back.

I haven't been able to reinstall Crouton yet because I currently am working overseas where many Google services are blocked ... one of them is the chromium source server needed to finish the setup.  Using the automatic proxy feature to download via VPN corrupts the Ubuntu packages (known bug in Ubuntu).  I'll probably have sync an internal chromium source server to finish this install.

Just to be clear: I was talking about the noise produced by the sound device itself. You can hear all kinds of high-frequency stuff there, especially on modern mobile hardware. The price for highly-integrated design, I guess. But yes, fans can be quite pesky buggers, too. ;-)