Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
Thanks!
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
[pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
_______________________________________________Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper cgclepper@gmail.com wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
_______________________________________________ Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined in s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper cgclepper@gmail.com wrote:
[pdinfo] is not part of vanilla. Â I can't (nor want to)Â use extended for this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. Â I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Â Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Â Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
_______________________________________________ Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I could not get PortAudio to work on ARM at all and Jack has issues with duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette msp@ucsd.edu wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined in s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper cgclepper@gmail.com
wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use extended for
this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps
running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is
there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the
console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
_______________________________________________ Pd-list@iem.atmailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Le 13/04/2014 22:42, Chris Clepper a écrit :
I could not get PortAudio to work on ARM at all and Jack has issues with duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
just an idea, what about using a signal (generated with sig~ or adc~) for checking if DSP is running, and send amplitude to another instance, or a daemon that would turn dsp on if signal isn't coming anymore, or kill and launch pd again if it doesn't respond to pings
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
I'm afraid callbacks would take a lot of CPU
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined in s_audio_pa.c). cheers Miller On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote: > There isn't a way to poll the DSP state in Pd Vanilla. > > -Jonathan > > On Saturday, April 12, 2014 8:47 PM, Chris Clepper <cgclepper@gmail.com <mailto:cgclepper@gmail.com>> wrote: > > [pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project. >
maybe you want to use pd-l2ork (works greatly on raspbian)
> On Saturday, April 12, 2014, Jonathan Wilkes <jancsika@yahoo.com <mailto:jancsika@yahoo.com>> wrote: > > On 04/12/2014 04:27 PM, Chris Clepper wrote: > > > >Hi list > >> > >> > >>I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely. > >> > >> > >>I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it? > >> > >> > >>Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies? > >In Pd-l2ork: > >[dsp-status( > >| > >[pdinfo] > > > >-Jonathan > > > > > > > >> > >>Thanks! > >> > >> > >> > >> > >>_______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Drat.
The mmap code only works for non-interleaved memory map interfaces. The only device I know of that works with the is the RME Hammerfall series.
I don't know if alsa supports any sort of mmap-ing for your hardware, but if so (and I guess it would be interleaved in that case) it might be worth hacking the mmap code to try that. It sounds less likely to hang than the read/write interface would be.
cheers Miller
On Sun, Apr 13, 2014 at 04:42:04PM -0400, Chris Clepper wrote:
I could not get PortAudio to work on ARM at all and Jack has issues with duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette msp@ucsd.edu wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined in s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper cgclepper@gmail.com
wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use extended for
this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps
running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is
there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the
console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
_______________________________________________ Pd-list@iem.atmailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Non-interleaved meaning data is sent (L,L,L then R,R,R per block) rather than the usual I2S/TDM method of interleaving channels per sample?
The ALSA folks have some mmap example code here that looks like a pretty generic interface:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
I will build that and see if the SoC hardware likes the mmap calls.
Thanks!
On Sun, Apr 13, 2014 at 8:46 PM, Miller Puckette msp@ucsd.edu wrote:
Drat.
The mmap code only works for non-interleaved memory map interfaces. The only device I know of that works with the is the RME Hammerfall series.
I don't know if alsa supports any sort of mmap-ing for your hardware, but if so (and I guess it would be interleaved in that case) it might be worth hacking the mmap code to try that. It sounds less likely to hang than the read/write interface would be.
cheers Miller
On Sun, Apr 13, 2014 at 04:42:04PM -0400, Chris Clepper wrote:
I could not get PortAudio to work on ARM at all and Jack has issues with duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette msp@ucsd.edu wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined
in
s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper <
cgclepper@gmail.com>
wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use extended
for
this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com
wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps
running for long periods like permanent installations. I get 'audio
I/O
stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but
is
there any long term issue with doing that? Will it reliably restart
audio
after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to
the
console. Perhaps there is a way to poll Pd for the internal DSP state
and
restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
Thanks!
Pd-list@iem.atmailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Correct...
But now I'm suddenly remembering that I once heard that it was precisely the lack of mmap interface that made it impossible (at least a year ago) to get jack running on Raspberry Pis - so I might easily be sending you on a wild goose chase.
OTOH I don't know what else to try - especially if portaudio isn't working.
M
On Sun, Apr 13, 2014 at 08:59:36PM -0400, Chris Clepper wrote:
Non-interleaved meaning data is sent (L,L,L then R,R,R per block) rather than the usual I2S/TDM method of interleaving channels per sample?
The ALSA folks have some mmap example code here that looks like a pretty generic interface:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
I will build that and see if the SoC hardware likes the mmap calls.
Thanks!
On Sun, Apr 13, 2014 at 8:46 PM, Miller Puckette msp@ucsd.edu wrote:
Drat.
The mmap code only works for non-interleaved memory map interfaces. The only device I know of that works with the is the RME Hammerfall series.
I don't know if alsa supports any sort of mmap-ing for your hardware, but if so (and I guess it would be interleaved in that case) it might be worth hacking the mmap code to try that. It sounds less likely to hang than the read/write interface would be.
cheers Miller
On Sun, Apr 13, 2014 at 04:42:04PM -0400, Chris Clepper wrote:
I could not get PortAudio to work on ARM at all and Jack has issues with duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette msp@ucsd.edu wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference this will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL defined
in
s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper <
cgclepper@gmail.com>
wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use extended
for
this project.
On Saturday, April 12, 2014, Jonathan Wilkes jancsika@yahoo.com
wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote:
Hi list > > >I'm wondering if there are any recommended ways to ensure DSP keeps
running for long periods like permanent installations. I get 'audio
I/O
stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
> > >I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but
is
there any long term issue with doing that? Will it reliably restart
audio
after Pd closes it?
> > >Also, the internal message [;pd audiostate( only returns data to
the
console. Perhaps there is a way to poll Pd for the internal DSP state
and
restart it if it dies?
In Pd-l2ork: [dsp-status( | [pdinfo]
-Jonathan
> >Thanks! > > > > >_______________________________________________
Pd-list@iem.atmailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmm, I'm using an armv7 chip which is much more up to date than the Pi CPU, so that might make things more possible. But the entire ARM on Linux has sent me down many weird alleys so far, I'm not expecting anything to be easy at this point. It's a lot like forcing x86 Linux to do audio 15 years ago!
On Sun, Apr 13, 2014 at 9:07 PM, Miller Puckette msp@ucsd.edu wrote:
Correct...
But now I'm suddenly remembering that I once heard that it was precisely the lack of mmap interface that made it impossible (at least a year ago) to get jack running on Raspberry Pis - so I might easily be sending you on a wild goose chase.
OTOH I don't know what else to try - especially if portaudio isn't working.
M
On Sun, Apr 13, 2014 at 08:59:36PM -0400, Chris Clepper wrote:
Non-interleaved meaning data is sent (L,L,L then R,R,R per block) rather than the usual I2S/TDM method of interleaving channels per sample?
The ALSA folks have some mmap example code here that looks like a pretty generic interface:
http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html
I will build that and see if the SoC hardware likes the mmap calls.
Thanks!
On Sun, Apr 13, 2014 at 8:46 PM, Miller Puckette msp@ucsd.edu wrote:
Drat.
The mmap code only works for non-interleaved memory map interfaces.
The
only device I know of that works with the is the RME Hammerfall series.
I don't know if alsa supports any sort of mmap-ing for your hardware,
but
if so (and I guess it would be interleaved in that case) it might be
worth
hacking the mmap code to try that. It sounds less likely to hang than
the
read/write interface would be.
cheers Miller
On Sun, Apr 13, 2014 at 04:42:04PM -0400, Chris Clepper wrote:
I could not get PortAudio to work on ARM at all and Jack has issues
with
duplex low latency.
What's the deal with the ALSA mmap code? Doesn't that use callbacks?
On Sun, Apr 13, 2014 at 2:55 PM, Miller Puckette msp@ucsd.edu
wrote:
You might have already tried this, but it might work better to use portaudio to get to ALSA - it can connect with ALSA using callbacks which the built-in ASA code doesn't. I don't know what difference
this
will make but perhaps it will help.
(try compiling with and without FAKEBLOCKING and THREADSIGNAL
defined
in
s_audio_pa.c).
cheers Miller
On Sat, Apr 12, 2014 at 07:26:56PM -0700, Jonathan Wilkes wrote:
There isn't a way to poll the DSP state in Pd Vanilla.
-Jonathan
On Saturday, April 12, 2014 8:47 PM, Chris Clepper <
cgclepper@gmail.com>
wrote:
[pdinfo] is not part of vanilla. I can't (nor want to) use
extended
for
this project.
On Saturday, April 12, 2014, Jonathan Wilkes <jancsika@yahoo.com
wrote:
On 04/12/2014 04:27 PM, Chris Clepper wrote: > >Hi list >> >> >>I'm wondering if there are any recommended ways to ensure DSP
keeps
running for long periods like permanent installations. I get
'audio
I/O
stuck' popping up every few days, which is not bad, but ideally
audio
should stay running indefinitely.
>> >> >>I can send a [metro 1000] to [;pd DSP 1( to keep audio going,
but
is
there any long term issue with doing that? Will it reliably
restart
audio
after Pd closes it?
>> >> >>Also, the internal message [;pd audiostate( only returns data
to
the
console. Perhaps there is a way to poll Pd for the internal DSP
state
and
restart it if it dies?
>In Pd-l2ork: >[dsp-status( >| >[pdinfo] > >-Jonathan > > > >> >>Thanks! >> >> >> >> >>_______________________________________________
Pd-list@iem.atmailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
I think the metronome solution will work - if DSP is already on the message has no effect, so this will only act to re-start hung-up audio.
Just curious - what OS/hardware is giving you the "audio stuck" messages? They shouldn't be happening at all.
cheers Miller
On Sat, Apr 12, 2014 at 04:27:02PM -0400, Chris Clepper wrote:
Hi list
I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely.
I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it?
Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies?
Thanks!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Chris Clepper -
Jonathan Wilkes -
Miller Puckette -
patrice colet