No subject

Tue Jun 15 12:32:34 CEST 2010

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 <august at alien.mur.at>:
>
> Okay, =A0glad 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,
>>>
>>> =A0 =A0 =A0Are you using MacOS X? =A0 What version of readanysf~? =A0Wh=
at version
>>> =A0 =A0 =A0of gavl and gmerlin_avdec are packaged with it/used with it?
>>>
>>> =A0 =A0 =A0I don't suspect it is the soundfile itself, but just in case=
, can you
>>> =A0 =A0 =A0put an example online for me. =A0 This is going to be a toug=
h bug to
>>> =A0 =A0 =A0find, unless you see some sort of regularity in how the soun=
d turns
>>> =A0 =A0 =A0to noise for you and can report that to me?
>>>
>>> =A0 =A0 =A0can you make a simple patch that isolates the bug?
>>>
>>> =A0 =A0 =A0Also, when the sound goes to noise, is it just that one part=
icular
>>> =A0 =A0 =A0soundfile that is used in readanysf or is it PD's entire out=
put. =A0In
>>> =A0 =A0 =A0other words, when you hear noise, can you also hear the othe=
r
>>> =A0 =A0 =A0readanysf's playing....or can you also make a simple osc~ an=
d hear it
>>> =A0 =A0 =A0play correctly?
>>>
>>> =A0 =A0 =A0The "Current file is either invalid or an unsupported codec.=
" warning
>>> =A0 =A0 =A0can also come if you send "play" to the readanysf object wit=
hout it
>>> =A0 =A0 =A0having a file loaded. =A0 I assume this is what is happening=
.
>>>
>>> =A0 =A0 =A0-a.
>>>
>>>> Hello August, list....
>>>>
>>>> I'm helping a student's installation, and we have created a patch whic=
h
>>>> 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 instantiate=
d
>>>> as [readanysf~ 1], in other words the block size and and buffer size a=
re
>>>> defaults.
>>>>
>>>> Sample terminal output is as follows while the patch is running:
>>>>
>>>> Created new readanysf~ with 1 channels and internal buffer of 24 * 64 =
=3D 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:
>>>>
>>>> =A0 =A0Unknown 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 =A0: 16
>>>> =A0 =A0Format =A0 =A0 =A0 =A0: 0x1 =3D> =A0WAVE_FORMAT_PCM
>>>> =A0 =A0Channels =A0 =A0 =A0: 1
>>>> =A0 =A0Sample Rate =A0 : 44100
>>>> =A0 =A0Block Align =A0 : 2
>>>> =A0 =A0Bit Width =A0 =A0 : 16
>>>> =A0 =A0Bytes/sec =A0 =A0 : 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 =A0 =A0 =A0: 70057260
>>>> Channels =A0 =A0: 1
>>>> Format =A0 =A0 =A0: 0x00010002
>>>> Sections =A0 =A0: 1
>>>> Seekable =A0 =A0: TRUE
>>>> Duration =A0 =A0: 00:26:28.600
>>>> Signal Max =A0: 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 report=
ed
>>>> 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"
>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinf=
o/pd-list
>
> --
> =A0 =A0 =A0 =A0-------------------
> =A0 =A0 =A0 =A0http://aug.ment.org
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo=
/pd-list
>

--0016e65b635a63c72a04899e1b09
Content-Type: application/octet-stream; name="stress.pd"
Content-Disposition: attachment; filename="stress.pd"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gaqr1myz0

I04gY2FudmFzIDUyNSA0MyA2MTEgNTY2IDEwOwojWCBvYmogOTIgNDU3IHJlYWRhbnlzZn47CiNY
IG9iaiA4OSAxNjcgKiAtMTsKI1ggb2JqIDg5IDE5MCBzZWwgLTEgMTsKI1ggb2JqIDg5IDE0MiBm
IDE7CiNYIG9iaiA4OSA1NCBibmcgMTUgMjUwIDUwIDAgZW1wdHkgZW1wdHkgZW1wdHkgMTcgNyAw
IDEwIC0yNjIxNDQgLTEKLTE7CiNYIG1zZyAxNzYgNTMgMDsKI1ggb2JqIDkyIDQ5MSBkYWN+Owoj
WCBvYmogMjE5IDMwNyBkZWwgNTA7CiNYIG9iaiA0NjkgMzA3IGRlbCA1MDsKI1ggbXNnIDIxOSAz
MjcgcGxheTsKI1ggbXNnIDQ2OSAzMjggcGxheTsKI1ggZmxvYXRhdG9tIDE2MSAxOTIgNyAwIDAg
MCAtIC0gLTsKI1ggb2JqIDE2MSAxNDIgZjsKI1ggb2JqIDE4NyAxNDIgKyAxOwojWCBvYmogODkg
OTggbWV0cm8gMTAwOwojWCBvYmogMTI5IDMwNyBkZWwgNTsKI1ggb2JqIDM4MCAzMDYgZGVsIDU7
CiNYIG1zZyAzNDUgMzA2IHN0b3A7CiNYIG1zZyA5MiAzMDcgc3RvcDsKI1ggbXNnIDEyOCAzMjcg
b3BlbiBmb28xLndhdjsKI1ggbXNnIDM3OSAzMjggb3BlbiBmb28yLndhdjsKI1ggY29ubmVjdCAw
IDAgNiAwOwojWCBjb25uZWN0IDAgMSA2IDE7CiNYIGNvbm5lY3QgMSAwIDIgMDsKI1ggY29ubmVj
dCAxIDAgMyAxOwojWCBjb25uZWN0IDIgMCAxOCAwOwojWCBjb25uZWN0IDIgMCA3IDA7CiNYIGNv
bm5lY3QgMiAwIDE1IDA7CiNYIGNvbm5lY3QgMiAxIDE3IDA7CiNYIGNvbm5lY3QgMiAxIDggMDsK
I1ggY29ubmVjdCAyIDEgMTYgMDsKI1ggY29ubmVjdCAzIDAgMSAwOwojWCBjb25uZWN0IDQgMCAx
NCAwOwojWCBjb25uZWN0IDUgMCAxMiAxOwojWCBjb25uZWN0IDUgMCAxNCAwOwojWCBjb25uZWN0
IDcgMCA5IDA7CiNYIGNvbm5lY3QgOCAwIDEwIDA7CiNYIGNvbm5lY3QgOSAwIDAgMDsKI1ggY29u
bmVjdCAxMCAwIDAgMDsKI1ggY29ubmVjdCAxMiAwIDEzIDA7CiNYIGNvbm5lY3QgMTIgMCAxMSAw
OwojWCBjb25uZWN0IDEzIDAgMTIgMTsKI1ggY29ubmVjdCAxNCAwIDMgMDsKI1ggY29ubmVjdCAx
NCAwIDEyIDA7CiNYIGNvbm5lY3QgMTUgMCAxOSAwOwojWCBjb25uZWN0IDE2IDAgMjAgMDsKI1gg
Y29ubmVjdCAxNyAwIDAgMDsKI1ggY29ubmVjdCAxOCAwIDAgMDsKI1ggY29ubmVjdCAxOSAwIDAg
MDsKI1ggY29ubmVjdCAyMCAwIDAgMDsK
--0016e65b635a63c72a04899e1b09--