Hi everyone, Sorry to interfere but I'm experiencing similar issues and cleaning up the headers doesn't seem to solve the problem ...
>From user's point of view (no dev skills in here !), it seems that pd gets overloaded by too many file's openings. On my system (osx 10.6, Pd-Ext 0.42.5-RC2, hcs' readanysf intel binary), and no matter the format and the size of the files, 240 successive openings lead to: "Invalid file or unsupported codec. Current file is either invalid or an unsupported codec" Then Pd refuses to save and reports : "error: /Users/me/Documents/PD/stress.pd: Too many open files" I join a simple "stress patch" that tries to isolate the error. Thanks for helping a bit more ! Cheers, Pierre 2010/6/21 august <[email protected]>: > > Okay, glad to hear you have it solved. > > If you can, please post an example of the soundfile that didn't work so > that I can test it. > > thanks-august. > > >> Hi August, >> >> thanks for your quick reply and sorry for my slow one ;-) The short >> answer is that cleaning up the headers of the soundfiles by re-encoding >> with sndfile-convert did the trick. Celine, the student I am working >> with, promised to write you a bit later with more details. >> >> Best! >> Derek >> >> On 6/15/10 5:31 PM, august wrote: >>> >>> Derek, >>> >>> Are you using MacOS X? What version of readanysf~? What version >>> of gavl and gmerlin_avdec are packaged with it/used with it? >>> >>> I don't suspect it is the soundfile itself, but just in case, can you >>> put an example online for me. This is going to be a tough bug to >>> find, unless you see some sort of regularity in how the sound turns >>> to noise for you and can report that to me? >>> >>> can you make a simple patch that isolates the bug? >>> >>> Also, when the sound goes to noise, is it just that one particular >>> soundfile that is used in readanysf or is it PD's entire output. In >>> other words, when you hear noise, can you also hear the other >>> readanysf's playing....or can you also make a simple osc~ and hear it >>> play correctly? >>> >>> The "Current file is either invalid or an unsupported codec." warning >>> can also come if you send "play" to the readanysf object without it >>> having a file loaded. I assume this is what is happening. >>> >>> -a. >>> >>>> Hello August, list.... >>>> >>>> I'm helping a student's installation, and we have created a patch which >>>> uses 24 instances of readanysf~ to read from 24 different soundfiles >>>> between 15min and one hour in length. All sound files are mono, 16 bit, >>>> 44.1KHz WAV_PCM format. >>>> >>>> The problem is that, after a length of time, the readanysf~ objects >>>> output noise rather than the soundfile. It is not the result of any >>>> single soundfile, and many or all of the readanysf~ objects can be >>>> affected by this simultaneously. >>>> >>>> I have attached the abstraction in question. The object is instantiated >>>> as [readanysf~ 1], in other words the block size and and buffer size are >>>> defaults. >>>> >>>> Sample terminal output is as follows while the patch is running: >>>> >>>> Created new readanysf~ with 1 channels and internal buffer of 24 * 64 = >>>> 1536 >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> Current file is either invalid or an unsupported codec. >>>> >>>> Opening each soundfile individually with readanysf~ and sending "play" >>>> and "pause" messages reports no errors whatsoever, however. >>>> >>>> I have sndfile-info data for all of the soundfiles. The only >>>> irregularity I see in this is one file which reports: >>>> >>>> Unknown chunk marker at position 6087587. Resynching. >>>> >>>> Besides that, most of the files report something like this: >>>> >>>> File : F_DOK6.wav >>>> Length : 146725772 >>>> RIFF : 146725764 >>>> WAVE >>>> bext : 602 >>>> fmt : 16 >>>> Format : 0x1 => WAVE_FORMAT_PCM >>>> Channels : 1 >>>> Sample Rate : 44100 >>>> Block Align : 2 >>>> Bit Width : 16 >>>> Bytes/sec : 88200 >>>> *** minf : 16 (unknown marker) >>>> *** elm1 : 7506 (unknown marker) >>>> data : 140114520 >>>> *** regn : 92 (unknown marker) >>>> *** umid : 24 (unknown marker) >>>> *** DGDA : 6602919 (unknown marker) >>>> End >>>> >>>> ---------------------------------------- >>>> Sample Rate : 44100 >>>> Frames : 70057260 >>>> Channels : 1 >>>> Format : 0x00010002 >>>> Sections : 1 >>>> Seekable : TRUE >>>> Duration : 00:26:28.600 >>>> Signal Max : 11627 (-9.00 dB) >>>> >>>> Someone suggested the noisy output may be the result of a buffer >>>> problem, but I am not sure who I could verify or correct this. >>>> >>>> I checked with "top" while the noise was happening and saw no evidence >>>> that Pd was using any more memory than usual, and the CPU meter reported >>>> 30%. >>>> >>>> Hardware is an Intel Mac Mini, software is Pd-Extended 0.41.4. >>>> >>>> Any suggestions or other diagnostics I could run are appreciated. >>>> >>>> Best! >>>> Derek >>>> -- >>>> ::: derek holzer ::: http://macumbista.net ::: >>>> ---Oblique Strategy # 136: >>>> "Remove specifics and convert to ambiguities" >>>> >>> >>> >>> >> >> -- >> ::: derek holzer ::: http://macumbista.net ::: >> ---Oblique Strategy # 6: >> "Abandon normal instruments" >> >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > -- > ------------------- > http://aug.ment.org > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
stress.pd
Description: Binary data
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
