> When you seek to a new position, there should still be data in the read > buffer (just like when playing sequentially).
Hmmm... that isn't true if the end of file has been reached. Ihave to think this through properly... Am 11. Sep. 2021, 09:58, um 09:58, Christof Ressi <[email protected]> schrieb: >> Note that [seek( could block as well, so we would have to >> >> 1) stop playback >> >> 2) [seek( >> >> 3) start playback after some delay >> >On a second thought, this is not really true. When you seek to a new >position, there should still be data in the read buffer (just like when > >playing sequentially). If not, it means that you would have to increase > >the read buffer size. > >So it seems like a [seek( method would be an overall improvement to >[readsf~]. I might give it a shot next week. > >Christof > >On 11.09.2021 02:53, Christof Ressi wrote: >> >> Here's some more background info: >> >> If [readsf~] notices that the read buffer is empty, it doesn't just >> output silence, instead it signals the I/O thread and waits until >data >> is available. This means that the outpout of [readsf~] is always >> deterministic! >> >> Now, if you call [1( right after [open(, the read buffer might still >> be empty on the next call of the perform routine, so [readsf~] can >> block for some time. >> >> I have added some debugging statements in the [readsf~] code to check > >> when and how long the perform routine blocks. >> >> First I use >> https://docs.microsoft.com/de-de/sysinternals/downloads/rammap to >> clear the file cache. Then I try to play a soundfile repeatedly >> without delay between [open( and [1(. These are the results: >> >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 5.931837 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.007390 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.169551 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.008211 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.129729 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.014779 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.137119 ms >> readsf~: wait... >> readsf~: ... done >> readsf~ blocked for 0.034896 ms >> >> Initially the file is not cached and Pd blocks for about 6 ms, but >> subsequent reads only block for a fraction of a milliseconds. >> >> But as IOhannes has pointed, this is very dependent on your OS, the >> size of the file and the overall state of the file cache. Often you >> can get away with reopening the file without delay, but it is not >100% >> safe, so you should better add a [delay]. If you want to loop without > >> gaps, you can actually use two [readsf~] objects and call [1( and >> [open( alternately. >> >> --- >> >> By the way, the help patch for [readsf~] really needs to be updated. >> It currently says: >> >>> You must open the soundfile in advance (a couple of seconds before >>> you'll need it) using the "open" message. >> This should really be "a couple of milliseconds". Also, we could add >> "... otherwise Pd might block" to make clear what happens. >> >> --- >> >> As a side note: it would be great if [readsf~] had something like a >> [seek( method, where you can seek to a specific sample onset. It's >> already possible with [open(, but it's a bit cumbersome and it would >> unnecessarily reopen the file. >> >> Note that [seek( could block as well, so we would have to >> >> 1) stop playback >> >> 2) [seek( >> >> 3) start playback after some delay >> >> Also, [readsf~] could have a "non-blocking" mode which would just >> output zeros as long as the buffer is empty - instead of blocking Pd. > >> Playback would be undeterministic, but in many scenarios this is not >> an issue. Looping would be as simple as connecting the right outlet >of >> [readsf~] to [seek 0(. >> >> Christof >> >> >> On 10.09.2021 17:18, IOhannes m zmoelnig wrote: >>> On 9/10/21 8:37 AM, Simon Iten wrote: >>>> hi there, >>>> >>>> I am finding conflicting (unclear) info on readsf~ behaviour. I >want to >>>> loop a long 8 channel wave file. >>>> here are my questions: >>>> >>>> -once i open the file with a message and after a delay start >>>> playback and >>>> it has finished (rightmost outlet bangs), can i restart playback >>>> without >>>> delay ([t b b] to open and 1 for start) or do I have to set a delay > >>>> again? >>>> (will the buffer somehow be ready faster) >>> >>> that depends on your OS. most likely the file will be cached, so >>> sequential opens should be fast (but this of course depends on how >>> large the file actually is). >>> >>> a 8-channel soundfile with 15minutes data and 16bit samples will >have >>> about 600MB at 44kHz. >>> that probably should be OK to cache (but then: do you have other >>> largish datasets that are loaded as well?) >>> >>>> >>>> -if above is not possible, what happens if the open message is sent >15 >>>> minutes before the 1 message to start playback, are there any >>>> downsides? >>>> the fact that I can set a buffer size seems to suggest that that >buffer >>>> will simply be filled and after that it waits for the playback to >>>> start. >>> >>> that is correct. >>> the delay is justa means to give Pd time to fill the buffer. >>> once the buffer is filled, Pd will just idle away until it starts >>> depleting. >>> >>> tg,dsr >>> IOhannes >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management >->https://lists.puredata.info/listinfo/pd-list >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >https://lists.puredata.info/listinfo/pd-list > > >------------------------------------------------------------------------ > >_______________________________________________ >[email protected] mailing list >UNSUBSCRIBE and account-management -> >https://lists.puredata.info/listinfo/pd-list
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
