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"
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"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 august@alien.mur.at:
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"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Â Â Â Â ------------------- Â Â Â Â http://aug.ment.org
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Seems that my first post has been truncated ...
---------- Forwarded message ----------
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
Seems that my first post has been truncated ...
---------- Forwarded message ----------
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
Pierre,
thanks for the report and for the test patch. However, I cannot
produce your error.
I am using ubuntu, pd 0.42.5
your test patch seems to work like it should here.
The "Too many open files" error is also not from readanysf~
can you explain a little further? Are you hearing noise like Derek
reported?
best -august.
This may or may not be related or useful, but: I got this 'too many files open' error a while ago in a patch with many readsf~ (without 'any') objects.
I did this:
edit /etc/security/limits.conf and add : [username] soft nofile 4096 [username] hard nofile 4096
(see http://ubuntuforums.org/showthread.php?t=638597 )
or some variation of it...
It seemed to help a bit, but still it happened now and then. The problem went away when I transfered the patch to a computer with more ram. But it is strange that playing a few sound files would require so much memory. I'm not sure if it's related at all to readsf~ or readanysf~. I got this error when using pix_image a few times too...
gr, Tim
2010/6/22 august august@alien.mur.at
Seems that my first post has been truncated ...
---------- Forwarded message ----------
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
Pierre,
thanks for the report and for the test patch. However, I cannot produce your error. I am using ubuntu, pd 0.42.5 your test patch seems to work like it should here. The "Too many open files" error is also not from readanysf~ can you explain a little further? Are you hearing noise like Derek reported? best -august.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi August,
Well, no unexpected noise here. I've tested with many various files (pd/doc/sound/voice.wav & bell.aiff included !) and the behaviour is always the same. At 240th opening, readanysf begins to report "invalid etc..." and then (after 2 or 3 more iterations) playback just stops. As already mentioned, when trying to save the patch, pd reports "error: /Users/me/Documents/PD/stress.pd: Too many open files". I've run the same test patch with readsf and errors went away. Sorry to sound redundant but I can't see extra clues ... Anyway, thanks for your reactivity.
Cheers,
Pierre
Le 22 juin 2010 à 18:48, august a écrit :
Seems that my first post has been truncated ...
---------- Forwarded message ----------
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
Pierre,
thanks for the report and for the test patch. However, I cannot produce your error.
I am using ubuntu, pd 0.42.5 your test patch seems to work like it should here.
The "Too many open files" error is also not from readanysf~
can you explain a little further? Are you hearing noise like Derek reported?
best -august.
On Tue, 22 Jun 2010, pierre cage wrote:
Seems that my first post has been truncated ...
I didn't see any truncation in the first post. Actually, your second post was the shorter one, because it quoted much less text from previous mails.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Tue, 22 Jun 2010, pierre cage wrote:
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"
Looks like this error message is wrong and the correct message is the one reported by Pd, isn't it ?
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.
I can't try the patch at this point, but can you try whether sending "pause" before re-sending "open" makes any difference, and whether sending "stop" before re-sending "open" makes any difference. this would be a useful hint to know, for people who want to try solving the problem.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
okay,
This error should no longer occur in the next release of
gavl/gmerlin_avdecode.
-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
Any idea when this will be released? I can update the Fink package
then.
.hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of gavl/gmerlin_avdecode.
-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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
It may take a little while for Burkhard to update his stuff. I have a feeling he is busy now with work, and also with adding webm and other features to gmerlin_avdec.
How about compiling a new readanysf~ for Mac? Do you still have it set up to do it (is it just a matter of putting in the new code)? Do you have a build system for putting it all together?
-a
Any idea when this will be released? I can update the Fink package
then..hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of gavl/gmerlin_avdecode.
-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
I don't remember, hopefully I sent you my build system changes. I
won't have time to do it in the near future, but I can answer
questions. Also, you could request access to the PdLab build machines
if you need to build on Mac OS X, Debian, Ubuntu and Windows.
http://puredata.info/docs/developer/PdLab
.hc
On Jul 8, 2010, at 4:25 AM, august wrote:
It may take a little while for Burkhard to update his stuff. I have a feeling he is busy now with work, and also with adding webm and other features to gmerlin_avdec.
How about compiling a new readanysf~ for Mac? Do you still have it set up to do it (is it just a matter of putting in the new code)? Do you have a build system for putting it all together?
-a
Any idea when this will be released? I can update the Fink package then.
.hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of gavl/gmerlin_avdecode.
-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
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
No, I didn't receive the build system changes. Do you remember how you packaged everything into one Mac bundle? I should be able to just reuse the gavl, gemerlin, ffmpeg, etc libs.
I'll write to the dev list and ask for access to the pdlab.
-a
I don't remember, hopefully I sent you my build system changes. I won't have time to do it in the near future, but I can answer questions. Also, you could request access to the PdLab build machines if you need to build on Mac OS X, Debian, Ubuntu and Windows.
http://puredata.info/docs/developer/PdLab
.hc
On Jul 8, 2010, at 4:25 AM, august wrote:
It may take a little while for Burkhard to update his stuff. I have a feeling he is busy now with work, and also with adding webm and other features to gmerlin_avdec.
How about compiling a new readanysf~ for Mac? Do you still have it set up to do it (is it just a matter of putting in the new code)? Do you have a build system for putting it all together?
-a
Any idea when this will be released? I can update the Fink package then.
.hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of gavl/gmerlin_avdecode.
-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
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
So I looked at the files again, this worked for me (I just added the
last step):
cd externals/august/readanysf~ make -f Makefile.darwin ./embed-MacOSX-dependencies.sh
If you want to make the same package as me, then just: cd .. zip -9r readanysf~.zip readanysf~
That folder just drops into /Library/Pd to install. :) I'll update
gavl and gmerlin on Mac OS X once Pd-extended 0.42.5 is released.
.hc
On Jul 10, 2010, at 6:07 AM, august wrote:
No, I didn't receive the build system changes. Do you remember how
you packaged everything into one Mac bundle? I should be able to just reuse the gavl, gemerlin, ffmpeg, etc libs.I'll write to the dev list and ask for access to the pdlab.
-a
I don't remember, hopefully I sent you my build system changes. I
won't have time to do it in the near future, but I can answer questions.
Also, you could request access to the PdLab build machines if you need to
build on Mac OS X, Debian, Ubuntu and Windows.http://puredata.info/docs/developer/PdLab
.hc
On Jul 8, 2010, at 4:25 AM, august wrote:
It may take a little while for Burkhard to update his stuff. I
have a feeling he is busy now with work, and also with adding webm and
other features to gmerlin_avdec.How about compiling a new readanysf~ for Mac? Do you still have it set up to do it (is it just a matter of putting in the new code)?
Do you have a build system for putting it all together?-a
Any idea when this will be released? I can update the Fink package then.
.hc
On Jul 3, 2010, at 5:50 AM, august wrote:
okay,
This error should no longer occur in the next release of gavl/gmerlin_avdecode.
-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
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne--
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hans,
if you download the latest code here
http://aug.ment.org/software/readanysf~0.40.tar.gz
..or, just go to the build lab and cd to
/Users/pddev/pure-data/trunk/externals/august/test/readanysf~0.40
you should be able to just type 'make'
I've changed the makefile so that it should recognize if you are a
mac intel or not.
It _should_ also create the MacOS-Intel binary package.
I just run the ./embed-MacOSX-dependencies.sh that I found on the
pdlab server on the directory with the *.pd_darwin binary and it
creates a "lib" directory with all the libs in it.
I'm making this blindly, so I don't know if it actually works.
-august.
So I looked at the files again, this worked for me (I just added the
last step):cd externals/august/readanysf~ make -f Makefile.darwin ./embed-MacOSX-dependencies.sh
If you want to make the same package as me, then just: cd .. zip -9r readanysf~.zip readanysf~
That folder just drops into /Library/Pd to install. :) I'll update gavl and gmerlin on Mac OS X once Pd-extended 0.42.5 is released.
.hc
-
august -
Derek Holzer -
Hans-Christoph Steiner -
Mathieu Bouchard -
Pierre Cage -
pierre cage
-
tim vets