Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-02 08:51, Jonathan Wilkes wrote: Of course these are just the latencies in the settings-- I haven't done the actual measurements yet. it would be interesting to have actual measurements. everything else is wild speculation. fgmadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGsP/8ACgkQkX2Xpv6ydvTNBQCg0TM1dreW18efrby4GyaEJGfk c2UAniL6+zW7ZbLqZjlGHqzueTSs7JUz =H2oS -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] issiconvert
Hello devs, Inspired by this thread ( http://lists.puredata.info/pipermail/pd-list/2013-05/102885.html) I spent the weekend doing exercises in writing simple conversions from int to symbol and vice versa, trying to get more used to the pd api. I ended up with a library of 8 classes I called `issiconvert'. --- Conversions with 4 different specifiers 0x, 0i, 0o, 0b: [int2shex]: `float 4095' - `symbol 0xfff' [int2sdec]: `float 4095' - `symbol 0i4095' [int2soct]: `float 4095' - `symbol 0o' [int2sbin]: `float 4095' - `symbol 0b' --- Symbol with any of the four specifiers to int: [sany2int]: `symbol 0xff' - `float 255' `symbol 0o377' - `float 255', etc. --- A simple version of zexy's symbol2list, but float instead of anything (`clist' means list of character values): [symbol2clist]: `symbol foo' - `list 102 111 111', `symbol 0i12' - `list 48 105 49 50' --- Does nothing except for printing the input if symbol: [symbol2symbol]: `symbol foo' - `symbol foo' --- Obvious: [strlen]: `symbol foo' - `float 3' --- Probably some, or possibly all of these functions already exist in some different way, but if some of you think this effort wasn't completely superfluous (except for my own experience) please tell me if you think names or specifiers should be changed or not. Then I could upload it somewhere (patch tracker, git repo on sourceforge or anywhere else) afterwards. Regards, --Funs ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: On 2013-06-02 08:51, Jonathan Wilkes wrote: Of course these are just the latencies in the settings-- I haven't done the actual measurements yet. it would be interesting to have actual measurements. everything else is wild speculation. Right. I would propose the following measurement protocol: (setup/usecase A: Pd only through ALSA) 1. In Pd using ALSA backend, run sine test signal in 'Media Test Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread. (setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVIfeature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd. 8. Report nominal + measured latencies for setup A and B, together with relevant hardware and system info. My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel: - setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency - setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer in JACK, 49.3 ms measured rountrip latency through Pd I would suggest we do Pd+PulseAudio-through-JACK discussion on pd-list if we continue this. The how-to and details of it are not a dev topic, though the consideration of writing direct PulseAudio support for Pd is. Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Midi overflow, when receiving Song Position Pointer (os x)
Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: warning: MIDI timing FIFO overflowed. When looking at the output of [midiin] I see 242 0 0 0 repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Midi overflow, when receiving Song Position Pointer (os x)
Seems like [midirealtimein] is working under os x (although there's an obsolete error message midirealtimein: works under MSW only). But when receiving a realtime messages (248, 250 or 252) [midiin] and [notein] output 0. Maybe this is related to the fifo overflow. Correction: the status byte for the song position pointer is 242 (dec - not hex) On 3.6.13 15:18 , Jan Baumgart wrote: Hi there, I'm experiencing a severe bug, when sending a Song Position Pointer message (0x242 0 0) to pd. After sending just one SPP message to pd, the status window says: warning: MIDI timing FIFO overflowed. When looking at the output of [midiin] I see 242 0 0 0 repeated endlessly. The Song Position Pointer message belongs to the System Common Messages and has two data bytes. Pd seems to get confused with this message. Where is the third data byte coming from? I'm running precompiled vanilla pd-0.44-3 from puckette's site on 32-bit intel mac (os x 10.6.8). I have a related second question: Is there any way to receive midi realtime messages with pd on os x? I'm trying to receive Midi Beat Clock... cheers, Jan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
From: katja katjavet...@gmail.com To: IOhannes m zmoelnig zmoel...@iem.at Cc: pddev pd-dev@iem.at Sent: Monday, June 3, 2013 7:09 AM Subject: Re: [PD-dev] jack dbus? On Mon, Jun 3, 2013 at 9:04 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: On 2013-06-02 08:51, Jonathan Wilkes wrote: Of course these are just the latencies in the settings-- I haven't done the actual measurements yet. it would be interesting to have actual measurements. everything else is wild speculation. Right. I would propose the following measurement protocol: (setup/usecase A: Pd only through ALSA) 1. In Pd using ALSA backend, run sine test signal in 'Media Test Audio and Midi...' 2. Set Pd's buffer to lowest possible value such that there are no I/O error messages or audible dropouts during 'normal Pd use', that is, while clicking (radio)buttons or switching between already loaded Pd windows. 3. For this nominal latency setting, measure actual roundtrip latency via line loopback or speaker / mic loopback, using patch latency-tester2.pd which was attached to my May 29 post in this thread. Ok, I just need a loopback cord. (I tried using [r~ foo]---[s~ foo] but when I drag the containing patch to move it down toward my physical connectors on the laptop, it goes outside the screen area and I can't tell whether it's lined up correctly with them. I think the problem is that my screen only bends down 45 degrees, so the patch doesn't end up on the same plane as the physical inputs. Also the wire in Pd is too far to the left so I probably can't even shove the objects far enough into the cavity to get them to connect without breaking the connection.) (setup/usecase B: Pd and PulseAudio through JACK/ALSA) 4. Set up a routing with Pd and PulseAudio as JACK clients. 5. In Pd, run the sine test signal. Simultaneously, play this video in a browser while routing it's sound through PulseAudio / JACK: http://www.youtube.com/watch?v=_63Cc6vPFVIfeature=youtu.be 6. For this combination, get the lowest nominal latency in Jack such that there are no I/O errors in Pd, or audible dropouts in either audio signal. JACK must be restarted for a new buffer setting to take effect. This is the most time-consuming aspect of the measurement. 7. For this routing and settings, measure the actual roundtrip latency through Pd. In all serious now... :) Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the JACK adds no latency statement and comparing additionally with just Pd running through JACK will simplify that. Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK. Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Regardless, we should all be using the same plugin for the comparison. (Or maybe just the same network stream through VLC, one using JACK backend and the other using the Pulse one.) My results for Panasonic CF-19 1 GHz Core2Duo, Xubuntu 12.04, built-in soundcard, no preemptive kernel: - setup/usecase A: 15 ms buffer in Pd, 18 ms measured roundtrip latency - setup/usecase B: 15 ms buffer in Pd, 23.2 ms (2*512 samples) buffer in JACK, 49.3 ms measured rountrip latency through Pd RFC: for the Pd preferences dialog, I think the delay entry box should be either disabled or replaced with a label that says set with JACK when the JACK api is chosen. On my system setting the delay from within Pd has no impact-- you can even set it to zero! -Jonathan ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
On Mon, Jun 3, 2013 at 9:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: [...] Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the JACK adds no latency statement and comparing additionally with just Pd running through JACK will simplify that. Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK. If I'm not mistaken, it was your original idea to test a setup where all audio sources can be played together with Pd, i.e. Pd + PulseAudio + JACK, and compare with Pd's current default routing (plain ALSA). So that's what I did. I'm now eager to know results from others before further delving into it. Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Flash plugin indeed (no problem with Pulse on Xubuntu). Should we better find an HTML5 stream for the test? [...] Katja ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
From: katja katjavet...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: IOhannes m zmoelnig zmoel...@iem.at; pddev pd-dev@iem.at Sent: Monday, June 3, 2013 6:23 PM Subject: Re: [PD-dev] jack dbus? On Mon, Jun 3, 2013 at 9:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: [...] Don't we want to compare straight to ALSA to pd to JACK to ALSA, just with Pd running? Having Pulse in the mix is good to measure as well, but I'd like to get a handle on the JACK adds no latency statement and comparing additionally with just Pd running through JACK will simplify that. Also, it may be helpful to add: Pd through JACK, VLC using JACK backend through Jack and compare it to the one using PulseAudio through JACK. If I'm not mistaken, it was your original idea to test a setup where all audio sources can be played together with Pd, i.e. Pd + PulseAudio + JACK, and compare with Pd's current default routing (plain ALSA). So that's what I did. I'm now eager to know results from others before further delving into it. Sorry, I'm talking about a few things at once. One would be to test Pd by itself with ALSA backend vs. Pd by itself with JACK backend. That would provide some data re: the page you linked to about latency. (My suggestion about Pd-JACK + VLC-with-jack-backend-JACK was meant to cover that case and also compare to Pd-JACK +Pulse-JACK, but as you say we can delve into that later.) The other is: what's a recommendable setup for using Pd in GNU/Linux with acceptable/controllable latency while still behaving with the rest of the system. Your Pd/Pulse/JACK measurements help to address that. So [when I find my cord] I'll give results for: Pd by itself directly to ALSA Pd by itself through JACK (with qjackctl, and with ALSA as JACK's backend) Pd to JACK + other stuff through Pulse to JACK Another question: what are you using to play the Youtube video? I know the proprietary Flash plugin caused problems with Pulse at one point. Flash plugin indeed (no problem with Pulse on Xubuntu). Should we better find an HTML5 stream for the test? Sure, if you have a link then that would be preferable-- I think HTML5 should have better coverage than proprietary Flash (at least Debian doesn't ship with it, which I like). Or if you have VLC, opening a stream there-- it has a Pulse backend as well as a JACK one so it'd be easy to test with both. (But if you don't then HTML5 is best.) -Jonathan [...] Katja___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
