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 ->