Hi IOhanens,
I moved this thread from the pd-list, since it is now only discussing pd's audio jack in c.
Did you ever find time to look at s_audio_jack.c again? I suspect it is a freebob -only problem, but I have only experienced it in pd. Somehow the buffer alignment is getting knocked off track - making JACK_NUM_PORTS smaller only seems to help this, but problems still arise when a big cpu hit occurs.
It is also curious that audacity can effectively reset the audio buffers coming from pd (or summed from both most likely) when it starts, but this cannot be done from pd. With JACK_NUM_PORTS > 512, pd even starts with audio residue.
Maybe I should file a bug or move this question to the jack list..
regards, Rich
On Wed, May 28, 2008 at 11:37 PM, zmoelnig@iem.at wrote:
Quoting Rich E reakinator@gmail.com:
After more testing...
With pd compiled with "JACK_NUM_PORTS 256", audio runs fine at first, but if the cpu gets a big hit, like when I open a soundfont in [fluid~], the audio falls behind and I get the pops/clicks again. If I compile pd with "JACK_NUM_PORTS 32", this doesn't appear to happen; [fluid~] does its thing, the gui freezes for a couple seconds, but the audio is fine afterwards.
Hopefully this hints at what the problem really is.
no, unfortunately this does not make sense at all. NUM_JACK_PORTS is only used for sizing arrays properly and setting the maximum possible numbers of channels Pd can use. as the default number of channels is still 2, jack should actually not notice anything about this parameter.
nevertheless, i will re-think....
(but i really need at least 64 channels, most likely more; this was the main motivation to start writing the entire patch...)
fgmads IOhannes
This message was sent using IMP, the Internet Messaging Program.
IOhannes,
First off, sorry for getting your name wrong in the last post :)
I just got a 64 Studio setup going with the latest pd-extended and jack/freebob - no wierd pops, it actually sounds great at about 5ms latency. So, Ubuntu looses I guess. There are other problems I was experiencing in Ubuntu (my touchpad would flip out on occasion, clicking on about 20 random things a second), so I guess the bug I found is going to have to stay an Ubuntu problem and not a pd dev problem.
Now, on to fiddle around in my new OS...
cheers, Rich
On Mon, Jun 9, 2008 at 10:49 PM, Rich E reakinator@gmail.com wrote:
Hi IOhanens,
I moved this thread from the pd-list, since it is now only discussing pd's audio jack in c.
Did you ever find time to look at s_audio_jack.c again? I suspect it is a freebob -only problem, but I have only experienced it in pd. Somehow the buffer alignment is getting knocked off track - making JACK_NUM_PORTS smaller only seems to help this, but problems still arise when a big cpu hit occurs.
It is also curious that audacity can effectively reset the audio buffers coming from pd (or summed from both most likely) when it starts, but this cannot be done from pd. With JACK_NUM_PORTS > 512, pd even starts with audio residue.
Maybe I should file a bug or move this question to the jack list..
regards, Rich
On Wed, May 28, 2008 at 11:37 PM, zmoelnig@iem.at wrote:
Quoting Rich E reakinator@gmail.com:
After more testing...
With pd compiled with "JACK_NUM_PORTS 256", audio runs fine at first, but if the cpu gets a big hit, like when I open a soundfont in [fluid~], the audio falls behind and I get the pops/clicks again. If I compile pd with "JACK_NUM_PORTS 32", this doesn't appear to happen; [fluid~] does its thing, the gui freezes for a couple seconds, but the audio is fine afterwards.
Hopefully this hints at what the problem really is.
no, unfortunately this does not make sense at all. NUM_JACK_PORTS is only used for sizing arrays properly and setting the maximum possible numbers of channels Pd can use. as the default number of channels is still 2, jack should actually not notice anything about this parameter.
nevertheless, i will re-think....
(but i really need at least 64 channels, most likely more; this was the main motivation to start writing the entire patch...)
fgmads IOhannes
This message was sent using IMP, the Internet Messaging Program.
Okay, scratch that... I just had the same problem in 64 Studio / Debian Etch. Bad audio, then I load audacity, and it goes away. Hmmm...
-rich
On Sat, Jun 21, 2008 at 1:24 AM, Rich E reakinator@gmail.com wrote:
IOhannes,
First off, sorry for getting your name wrong in the last post :)
I just got a 64 Studio setup going with the latest pd-extended and jack/freebob - no wierd pops, it actually sounds great at about 5ms latency. So, Ubuntu looses I guess. There are other problems I was experiencing in Ubuntu (my touchpad would flip out on occasion, clicking on about 20 random things a second), so I guess the bug I found is going to have to stay an Ubuntu problem and not a pd dev problem.
Now, on to fiddle around in my new OS...
cheers, Rich
On Mon, Jun 9, 2008 at 10:49 PM, Rich E reakinator@gmail.com wrote:
Hi IOhanens,
I moved this thread from the pd-list, since it is now only discussing pd's audio jack in c.
Did you ever find time to look at s_audio_jack.c again? I suspect it is a freebob -only problem, but I have only experienced it in pd. Somehow the buffer alignment is getting knocked off track - making JACK_NUM_PORTS smaller only seems to help this, but problems still arise when a big cpu hit occurs.
It is also curious that audacity can effectively reset the audio buffers coming from pd (or summed from both most likely) when it starts, but this cannot be done from pd. With JACK_NUM_PORTS > 512, pd even starts with audio residue.
Maybe I should file a bug or move this question to the jack list..
regards, Rich
On Wed, May 28, 2008 at 11:37 PM, zmoelnig@iem.at wrote:
Quoting Rich E reakinator@gmail.com:
After more testing...
With pd compiled with "JACK_NUM_PORTS 256", audio runs fine at first, but if the cpu gets a big hit, like when I open a soundfont in [fluid~], the audio falls behind and I get the pops/clicks again. If I compile pd with "JACK_NUM_PORTS 32", this doesn't appear to happen; [fluid~] does its thing, the gui freezes for a couple seconds, but the audio is fine afterwards.
Hopefully this hints at what the problem really is.
no, unfortunately this does not make sense at all. NUM_JACK_PORTS is only used for sizing arrays properly and setting the maximum possible numbers of channels Pd can use. as the default number of channels is still 2, jack should actually not notice anything about this parameter.
nevertheless, i will re-think....
(but i really need at least 64 channels, most likely more; this was the main motivation to start writing the entire patch...)
fgmads IOhannes
This message was sent using IMP, the Internet Messaging Program.
-
Rich E