|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | > [[Main Page]] > [[Piano Expander based on Pianotec and Odroid-N2]]
| + | ==''' [[Piano_Expander_based_on_Pianoteq_and_Odroid-N2|Sorry - a big mistake - a typo in the name of Pianoteq - please used this link to follow the corrected web-page]]'''== |
| − | | |
| − | ----
| |
| − | | |
| − | == '''ARM 32 vs. AARCH64''' == | |
| − | * [https://www.cnx-software.com/2016/03/01/64-bit-arm-aarch64-instructions-boost-performance-by-15-to-30-compared-to-32-bit-arm-aarch32-instructions/ CNX-Software: 64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions]
| |
| − | * I still hope, that [https://www.modartt.com/ Modartt] will provide [https://www.modartt.com/pianoteq Pianoteq] sometimes compiled for AARCH64 architecture. In my opinion 32-bit code on any ARM module (Raspberry PI, Banana PI, Odroid etc.) which could also use AARCH64 code doesn't make sense. Modules which provide only ARM-32 bit architecture don't have the calculation power for Pianoteq. So why should those CPUs be supported? Canceling 32-bit support and switching to AARCH64 would be the right way....
| |
| − | | |
| − | ==''' Pianotec 6 Stage Installation on Odroid '''==
| |
| − | * coming soon
| |
| − | | |
| − | === Some pictures ===
| |
| − | | |
| − | [[File:First-Test-Setup-2.jpg|300px]] [[File:First-Test-Setup-1.jpg|300px]]
| |
| − | | |
| − | [[File:Piano-Expander-Bechstein.jpg|300px]] [[File:Piano-Expander-MK2.jpg|300px]]
| |
| − | | |
| − | ==''' CPU Performance Benchmarks '''==
| |
| − | === Benchmark by Marcos Daniel ===
| |
| − | *[https://github.com/marcosdanielfl/ptq_bench/blob/master/ptq_benc.c Github: ptq_bench.c]
| |
| − | ==== What the code does - description by Marcos Daniel ====
| |
| − | <pre>
| |
| − | It is a stress test, the program generates a MIDI file with ten glissandi
| |
| − | from the lowest A to the top C, (on white keys).
| |
| − | The damper pedal is down during each glissandi.
| |
| − | In the first try, every note takes is played 100ms after the previous one.
| |
| − | The program asks if there was an error in the playback, if there is not
| |
| − | overload, you press "y" and it will generate another MIDI file, this time
| |
| − | with 50ms between notes.
| |
| − | So the sequence of notes duration is (geometric progression) 100ms, 50ms,
| |
| − | 25ms, 12.5ms, 6.25 ms, and so on.
| |
| − | When the computing power is not enough, an overload will occur, let's suppose
| |
| − | it happens whith 12.5ms of delay, then the next delay will be the average of
| |
| − | 12.5ms and 25ms (the lowest time without overload) = 18.75ms, if there is
| |
| − | not error, next duration will be average between this last value and the
| |
| − | maximum time with error, i.e. (18.75 + 12.5)/2 = 15.625ms.
| |
| − | By doing this, quiclky one obtains a final result (10 or 12 tries), and when
| |
| − | asked pressing key "t" (for terminate) the program exits.
| |
| − | Any run can be skipped by ctrl+c.
| |
| − | The program is "as is", and in Spanish.
| |
| − | At last, but not least, on odroid XU4, it run more consistentlyif you run
| |
| − | Pianoteq (or this test) from big cores excluding small ones, this can be
| |
| − | done by taskset command, in case of XU4, big cores are numbered from
| |
| − | 4 to 7, so the command would be
| |
| − | taskset 0xF0 [command]. There is some improvement if you use less niceness,
| |
| − | for instance I ran most testst this way:
| |
| − | nice -10 taskset 0xF0 ./ptq_bench
| |
| − | Pianoteq executable file must be in the same folder and version removed,
| |
| − | simply named "Pianoteq".
| |
| − | </pre>
| |
| − | | |
| − | ==== Results ====
| |
| − | * coming soon
| |
| − | | |
| − | ----
| |
| − | | |
| − | > [[Main Page]] > [[Piano Expander based on Pianotec and Odroid-N2]]
| |