[PD] shmem and bigger buffer size
iftah gabbai
ift.gab at gmail.com
Tue Feb 11 09:20:02 CET 2020
thank you Christof for the help and cyrille for the excellent work,
breaking it to chunks did the trick!
On Mon, Feb 10, 2020 at 2:01 PM Christof Ressi <info at christofressi.com>
wrote:
> > when you suggest to spread the op across several dsp ticks you mean for
> example not to read the buffer in one go but to break the read to chunks?
>
> Yes.
>
> > also, is there a way to "defer low" different tasks in pd?
>
> Not yet, but I've proposed adding such functionality to Pd's API, so it
> can be used by Pd itself (e.g. for [soundfiler] and also by externals. I
> already made a working async task queue (for one of my externals), I
> basically just have to port it from C++ to C and make a PR, but I didn't
> have time yet :-(
>
> Christof
> On 10.02.2020 13:04, iftah gabbai wrote:
>
> thanks Christof, unfortunately increasing the delay is not an option for
> me,
> when you suggest to spread the op across several dsp ticks you mean for
> example not to read the buffer in one go but to break the read to chunks?
> also, is there a way to "defer low" different tasks in pd?
>
> On Mon, Feb 10, 2020 at 12:53 PM Christof Ressi <info at christofressi.com>
> wrote:
>
>> > when i setmem /dumpmem on a 5760000 samples size buffer
>>
>> Are you trying to do this in a single DSP tick? This would create a CPU
>> spike and lead to audio dropouts, depending on the value of "delay" in the
>> audio settings.
>>
>> You can either
>>
>> a) increase "delay" -> more latency -> more chance to "absorb" CPU
>> spikes, or
>>
>> b) spread the operation across several DSP ticks.
>>
>> Christof
>> On 10.02.2020 12:38, iftah gabbai wrote:
>>
>> so i tested it with linux and it works great, my only problem right now
>> is that i get an audible glitch when i setmem /dumpmem on a 5760000 samples
>> size buffer, i tried breaking the setting / dumping to smaller chunks but
>> it only got worse, is there any workaround?
>>
>> thanks!
>>
>> On Sat, Feb 1, 2020 at 11:44 AM cyrille henry <ch at chnry.net> wrote:
>>
>>> yes, I did write that. But Miller implemented a binary transfer from pd
>>> to pd~ so the native solution must be lot's more efficient now. I did not
>>> test if shmem is still faster.
>>>
>>> Yes, using shmem_send~ and shmem_receive~ will add 1 more block latency
>>> on top of pd~ latency.
>>>
>>> cheers
>>>
>>>
>>> Le 01/02/2020 à 10:32, iftah gabbai a écrit :
>>> > @cyrille, i have another question if i may, i saw somewhere in the
>>> list that you write that streaming audio from pd to a subprocess with shmem
>>> is much more efficient in terms of cpu usage, is it still the case? also if
>>> i understand correctly from the docs i will then have latency of one block
>>> size + fifo right?
>>> >
>>> > On Sat 1. Feb 2020 at 10:29, iftah gabbai <ift.gab at gmail.com <mailto:
>>> ift.gab at gmail.com>> wrote:
>>> >
>>> > @chris, thank you for that, very good piece of info!
>>> >
>>> > On Fri 31. Jan 2020 at 20:03, cyrille henry <ch at chnry.net <mailto:
>>> ch at chnry.net>> wrote:
>>> >
>>> >
>>> >
>>> > Le 31/01/2020 à 18:30, iftah gabbai a écrit :
>>> > > so it is confirmed to work on linux? if so than great :)
>>> > it's working on my computer!
>>> > c
>>> >
>>> >
>>> > >
>>> > > On Fri 31. Jan 2020 at 13:58, cyrille henry <ch at chnry.net
>>> <mailto:ch at chnry.net> <mailto:ch at chnry.net <mailto:ch at chnry.net>>>
>>> wrote:
>>> > >
>>> > > I don't know why it fail on mac. You can try to split
>>> in smaller table, like you suggested.
>>> > > But you should also test it on linux first since it's
>>> your main target.
>>> > >
>>> > > c
>>> > >
>>> > > Le 30/01/2020 à 19:55, iftah gabbai a écrit :
>>> > > > im building on mac os 10.12 and intending to run on
>>> linux(arm), i haven’t tested on linux, the problems im having are on mac,
>>> > > >
>>> > > > thanks!
>>> > > >
>>> > > > On Thu 30. Jan 2020 at 17:47, cyrille henry <
>>> ch at chnry.net <mailto:ch at chnry.net> <mailto:ch at chnry.net <mailto:
>>> ch at chnry.net>> <mailto:ch at chnry.net <mailto:ch at chnry.net> <mailto:
>>> ch at chnry.net <mailto:ch at chnry.net>>>> wrote:
>>> > > >
>>> > > > what is your OS?
>>> > > >
>>> > > > Le 30/01/2020 à 17:10, iftah gabbai a écrit :
>>> > > > > hey C, i have 16gb of ram, and if i did not
>>> completely messed up my calcs i tried to allocate 2 min of 96khz
>>> (11.520.000)
>>> > > > >
>>> > > > > thanks again!
>>> > > > >
>>> > > > > On Thu 30. Jan 2020 at 17:06, cyrille henry <
>>> ch at chnry.net <mailto:ch at chnry.net> <mailto:ch at chnry.net <mailto:
>>> ch at chnry.net>> <mailto:ch at chnry.net <mailto:ch at chnry.net> <mailto:
>>> ch at chnry.net <mailto:ch at chnry.net>>> <mailto:ch at chnry.net <mailto:
>>> ch at chnry.net> <mailto:ch at chnry.net <mailto:ch at chnry.net>> <mailto:
>>> ch at chnry.net <mailto:ch at chnry.net> <mailto:ch at chnry.net <mailto:
>>> ch at chnry.net>>>>> wrote:
>>> > > > >
>>> > > > > hello,
>>> > > > >
>>> > > > > Do you have enough free memory on your
>>> computer?
>>> > > > > I just test on y computer, I can
>>> reproduce this error as soon as I ask an allocation bigger than the
>>> available memory on my hardware.
>>> > > > > (between 500 000 000 and 1 000 000 000
>>> points)
>>> > > > >
>>> > > > > cheers
>>> > > > > Cyrille
>>> > > > >
>>> > > > > Le 30/01/2020 à 12:11, iftah gabbai a
>>> écrit :
>>> > > > > > ...perhaps i should elaborate, im
>>> trying to dump an array in the size of 11 520 000(2 min of 96 khz audio) to
>>> another instance of PD, is it possible at all or do i have to break it to
>>> smaller chunks?
>>> > > > > >
>>> > > > > > On Thu, Jan 30, 2020 at 12:01 PM iftah
>>> gabbai <ift.gab at gmail.com <mailto:ift.gab at gmail.com> <mailto:
>>> ift.gab at gmail.com <mailto:ift.gab at gmail.com>> <mailto:ift.gab at gmail.com
>>> <mailto:ift.gab at gmail.com> <mailto:ift.gab at gmail.com <mailto:
>>> ift.gab at gmail.com>>> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com>
>>> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com>> <mailto:
>>> ift.gab at gmail.com <mailto:ift.gab at gmail.com> <mailto:ift.gab at gmail.com
>>> <mailto:ift.gab at gmail.com>>>> <mailto:ift.gab at gmail.com <mailto:
>>> ift.gab at gmail.com> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com>>
>>> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com> <mailto:
>>> ift.gab at gmail.com <mailto:ift.gab at gmail.com>>> <mailto:ift.gab at gmail.com
>>> <mailto:ift.gab at gmail.com> <mailto:ift.gab at gmail.com <mailto:
>>> ift.gab at gmail.com>> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com>
>>> <mailto:ift.gab at gmail.com <mailto:ift.gab at gmail.com>>>>>> wrote:
>>> > > > > >
>>> > > > > > hello all, ive been experimenting
>>> with shmem (the latest one i could find in deken), it works fine as long as
>>> i use very small arrays, as soon as i try to use bigger arrays ( havent
>>> checked where the breakpoint is but more than approx 400000) it doesnt and
>>> it returns "could not allocate shmem memory Id"
>>> > > > > >
>>> > > > > > i wonder if im doing something
>>> wrong or if its a known thing?
>>> > > > > >
>>> > > > > >
>>> > > > > > thanks!
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> _______________________________________________
>>> > > > > > Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>>>> mailing list
>>> > > > > > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> _______________________________________________
>>> > > > > Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>>>> mailing list
>>> > > > > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> > > > >
>>> > > > >
>>> > > > >
>>> _______________________________________________
>>> > > > > Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at> <mailto:Pd-list at lists.iem.at <mailto:
>>> Pd-list at lists.iem.at>>> mailing list
>>> > > > > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> > > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>
>>> <mailto:Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>> <mailto:
>>> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> <mailto:
>>> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>>> mailing list
>>> > > > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> <mailto:
>>> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at>> mailing list
>>> > > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> > >
>>> >
>>> >
>>> > _______________________________________________
>>> > Pd-list at lists.iem.at mailing list
>>> > UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> >
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>>
>>
>> _______________________________________________Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
> _______________________________________________Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200211/dff41a30/attachment-0001.html>
More information about the Pd-list
mailing list