Chris | 1 Mar 08:02 2012
Picon

Re: PortAudio and Lazarus

Hi Peter -

The problem turned out to be on my end. There are two folders:
PortMediaTest_10 and PortMediaTest. I had copied the latter to a
different directory and this apparently messed up the build
envinronment. I tried launching the TestPAbasicLCL.lpi file with the
original directory structure and it compiled.

May I suggest that a short how-to be written for those of us who are
not Lazarus experts which explains these steps? There is very little in
the way of documentation in this package and a how-to would have saved
both of us time and effort.

Many thanks for your help in solving this,

Chris
Anil Vaitla | 1 Mar 21:39 2012
Picon

Example Use Case

Hi There!


Thanks for all the help to the port audio community, and everyone who contributes to the project. I wrote a few weeks back about using FFT with portaudio, and I have finally finished, and thought I might share, since I think it's kind of cool. It is a command line music player and visualizer tool being used here: http://www.youtube.com/watch?v=KOp9SHMuZOw.

It's actually coded with the Haskell Programming Language using FFI bindings to portaudio. There were some issues, such as latency and garbage collection, but doing things carefully can remove most of these problems. The original bindings were written excellently by Jon Van Enk, but there was some problems with the high level api, so hopefully, if there is any one else interested in Haskell, Jon and I might be able to push the new version to Hackage soon enough (or you can just grab it from github)!

Thanks for reading and all the help!

Anil
_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Alan Horstmann | 1 Mar 23:45 2012
Picon

Tests: paqa_latency issues and fixes

Hi all,

I am working through the Portaudio tests on Linux, and have found a number of 
issues and bugs.  First up is paqa_latency, which has the most so far.

The defines SAMPLE_RATE and FRAMES_PER_BUFFER are not actually used - it is 
thus pointless to print them out.  The sample rate is separately hard-coded 
to 44100 in 2 places.  This means that any devices (there are some on this 
machine) that only operate at 48000Hz are bound to fail.  Instead I have used 
the device default sample rate for the tests.  The defines then could be 
removed.

At present if one paqaCheckMultipleSuggested() fails the whole qa-test is 
abandoned.  By instead noting that failure and continuing with other checks 
there is more rapid coverage.

When the lowlatency == highlatency, numLoops is set to 1.  The following 
calculation for latency:
    lowLatency + ((highLatency - lowLatency) * i /(numLoops - 1))
then blows up and 'nan' is passed to OpenStream() as the latency value, 
causing that to fail!  An extra check deals with this condition (where the 
device only accepts one value).

A couple of extra '\n's and fixing a printf typo make the output more 
readable.

Here is a diff of changes I have made here (also attached to avoid wordwrap).
"qa_latency_fixes.diff"

Regards

Alan

diff -ru ../orig/qa/paqa_latency.c ./qa/paqa_latency.c
--- ../orig/qa/paqa_latency.c	2011-09-08 10:29:21.000000000 +0100
+++ ./qa/paqa_latency.c	2012-03-01 20:45:41.000000000 +0000
 <at>  <at>  -220,7 +220,7  <at>  <at> 
     double lowLatency;
     double highLatency;
     double finalLatency;
-    double sampleRate = 44100.0;
+    double sampleRate = SAMPLE_RATE;
     const PaDeviceInfo *pdi = Pa_GetDeviceInfo( deviceIndex );
     double previousLatency = 0.0;
     int numChannels = 1;
 <at>  <at>  -243,10 +243,12  <at>  <at> 
     streamParameters.device = deviceIndex;
     streamParameters.hostApiSpecificStreamInfo = NULL;
     streamParameters.sampleFormat = paFloat32;
+    sampleRate = pdi->defaultSampleRate;

     printf(" lowLatency  = %g\n", lowLatency );
     printf(" highLatency = %g\n", highLatency );
     printf(" numChannels = %d\n", numChannels );
+    printf(" sampleRate  = %g\n", sampleRate );

     if( (highLatency - lowLatency) < 0.001 )
     {
 <at>  <at>  -255,7 +257,10  <at>  <at> 
 	
     for( i=0; i<numLoops; i++ )
     {   
-        streamParameters.suggestedLatency = lowLatency + ((highLatency - 
lowLatency) * i /(numLoops - 1.0));
+        if( numLoops == 1 )
+            streamParameters.suggestedLatency = lowLatency;
+        else
+            streamParameters.suggestedLatency = lowLatency + ((highLatency - 
lowLatency) * i /(numLoops - 1));

         printf("   suggestedLatency[%d] = %6.4f\n", i, 
streamParameters.suggestedLatency );

 <at>  <at>  -307,14 +312,16  <at>  <at> 
     for( id=0; id<numDevices; id++ )            /* Iterate through all 
devices. */
     {
         pdi = Pa_GetDeviceInfo( id );
-        printf("Using device #%d: '%s' (%s)\n", id, pdi->name, 
Pa_GetHostApiInfo(pdi->hostApi)->name);
+        printf("\nUsing device #%d: '%s' (%s)\n", id, pdi->name, 
Pa_GetHostApiInfo(pdi->hostApi)->name);
         if( pdi->maxOutputChannels > 0 )
         {
-            if( (result = paqaCheckMultipleSuggested( id, 0 )) != 0 ) goto 
error;        
+            if( (result = paqaCheckMultipleSuggested( id, 0 )) != 0 )
+                printf("OUTPUT CHECK FAILED !!! #%d: '%s'\n", id, pdi->name);
         }
         if( pdi->maxInputChannels > 0 )
         {
-            if( (result = paqaCheckMultipleSuggested( id, 1 )) != 0 ) goto 
error;   
+            if( (result = paqaCheckMultipleSuggested( id, 1 )) != 0 )
+                printf("INPUT CHECK FAILED !!! #%d: '%s'\n", id, pdi->name);
         }
     }
     return 0;
 <at>  <at>  -337,7 +344,7  <at>  <at> 
         if( pdi->maxOutputChannels > 0 )
         {
             printf("  Output defaultLowOutputLatency  = %f seconds\n", 
pdi->defaultLowOutputLatency);
-            printf("  Output info: defaultHighOutputLatency = %f seconds\n", 
pdi->defaultHighOutputLatency);
+            printf("  Output defaultHighOutputLatency = %f seconds\n", 
pdi->defaultHighOutputLatency);
             QA_ASSERT_TRUE( "defaultLowOutputLatency should be > 0", 
(pdi->defaultLowOutputLatency > 0.0) );
             QA_ASSERT_TRUE( "defaultHighOutputLatency should be > 0", 
(pdi->defaultHighOutputLatency > 0.0) );
             //QA_ASSERT_TRUE( "defaultHighOutputLatency should be > Low", 
(pdi->defaultHighOutputLatency > pdi->defaultLowOutputLatency) );
 <at>  <at>  -368,9 +375,9  <at>  <at> 
     const PaDeviceInfo *deviceInfo;
     int i;
     int framesPerBuffer;
-    double sampleRate = 44100;
+    double sampleRate = SAMPLE_RATE;

-    printf("PortAudio QA: investigate output latency. SR = %d, BufSize = 
%d\n", SAMPLE_RATE, FRAMES_PER_BUFFER);
+    printf("\nPortAudio QA: investigate output latency.\n");

     /* initialise sinusoidal wavetable */
     for( i=0; i<TABLE_SIZE; i++ )
 <at>  <at>  -396,9 +403,11  <at>  <at> 
     outputParameters.channelCount = 2;       /* stereo output */
     outputParameters.sampleFormat = paFloat32; /* 32 bit floating point 
output */
     deviceInfo = Pa_GetDeviceInfo( outputParameters.device );
-    printf("Using device #%d: '%s' (%s)\n", outputParameters.device, 
deviceInfo->name, Pa_GetHostApiInfo(deviceInfo->hostApi)->name);
+    printf("\nUsing device #%d: '%s' (%s)\n", outputParameters.device, 
deviceInfo->name, Pa_GetHostApiInfo(deviceInfo->hostApi)->name);
     printf("Device info: defaultLowOutputLatency  = %f seconds\n", 
deviceInfo->defaultLowOutputLatency);
     printf("Device info: defaultHighOutputLatency = %f seconds\n", 
deviceInfo->defaultHighOutputLatency);
+    sampleRate = deviceInfo->defaultSampleRate;
+    printf("Sample Rate for following tests: %g\n", sampleRate);
     outputParameters.hostApiSpecificStreamInfo = NULL;

     // Try to use a small buffer that is smaller than we think the device can 
handle.
Attachment (qa_latency_fixes.diff): text/x-diff, 4603 bytes
_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Phil Burk | 2 Mar 03:05 2012

Re: Tests: paqa_latency issues and fixes

Hello Alan,

On 3/1/12 2:45 PM, Alan Horstmann wrote:
> I am working through the Portaudio tests on Linux, and have found a
> number of issues and bugs.  First up is paqa_latency, which has the
> most so far.

Those look like good changes to make to "paqa_latency.c".

The various QA tests have been very useful so far. But they are far from
perfect. I'm glad you are working through them.

Phil Burk
Peter Shaw | 2 Mar 08:33 2012

Write to Disk Performance - what is your opinion?


hi Folks,

With a Lot of help from this list i leared a lot and scribble my first audio Recorder application. It's
recording the audiostream from my soundcard direct to 10minutes mp3 files. I will distribute these   Files
via torrent, provide with a own tracker. All torrents containing the next torrent url, so it will be
passible to write a player that continiously load the whole 6h clubset or liveconcert...

What do you think is better: writte every recorded buffer to disk, or buffer the encoded buffer and write
this larger buffer to disk an once? (Maybe all 30 seconds?)

Thanx a Lot,
Peter

--
T: http://twitter.com/peter_shaw
F: http://facebook.com/PeterDunstonShaw
B: http://unthoughted.wordpress.com
V: 0177 3283056
.
ynnhoj reim | 2 Mar 08:38 2012
Picon

Re: Write to Disk Performance - what is your opinion?

hi pet

I think its a good idea to write every recorded buffer to disk to be able to save memory, because in the long run if you were running many applications that requires more memory that would be useful...

-john
From: Peter Shaw <unthoughted <at> googlemail.com>
To: Portaudio Mailing List <portaudio <at> music.columbia.edu>
Sent: Friday, March 2, 2012 4:33 PM
Subject: [Portaudio] Write to Disk Performance - what is your opinion?


hi Folks,

With a Lot of help from this list i leared a lot and scribble my first audio Recorder application. It's recording the audiostream from my soundcard direct to 10minutes mp3 files. I will distribute these  Files via torrent, provide with a own tracker. All torrents containing the next torrent url, so it will be passible to write a player that continiously load the whole 6h clubset or liveconcert...

What do you think is better: writte every recorded buffer to disk, or buffer the encoded buffer and write this larger buffer to disk an once? (Maybe all 30 seconds?)

Thanx a Lot,
Peter

--
T: http://twitter.com/peter_shaw
F: http://facebook.com/PeterDunstonShaw
B: http://unthoughted.wordpress.com
V: 0177 3283056
.


_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio


_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Alan Wolfe | 2 Mar 08:39 2012
Picon

Re: Write to Disk Performance - what is your opinion?

well, when in doubt you should profile and see which is better (just to be sure!) but i personally would lean towards writing your data pretty much as its generated (ie write buffers when they are full maybe).


My reasoning for this is that the file system / standard C file functions already have some file buffering stuff in place that is fairly sophisticated.  I would think you'd be better off leaving the data in the hands of those systems so they can decide when it's best to actually do the writes to the disk.

Of course, if you are doing a ton of tiny writes (ie if you fwrite a byte at a time) you would have excessive function call overhead (and probably some other overhead from the internal buffers resizing etc) but if you are doing at least a few hundred bytes or a 1k or more, id bet you'd be ok.

But yeah, profile to make sure!

On Thu, Mar 1, 2012 at 11:33 PM, Peter Shaw <unthoughted <at> googlemail.com> wrote:

hi Folks,

With a Lot of help from this list i leared a lot and scribble my first audio Recorder application. It's recording the audiostream from my soundcard direct to 10minutes mp3 files. I will distribute these   Files via torrent, provide with a own tracker. All torrents containing the next torrent url, so it will be passible to write a player that continiously load the whole 6h clubset or liveconcert...

What do you think is better: writte every recorded buffer to disk, or buffer the encoded buffer and write this larger buffer to disk an once? (Maybe all 30 seconds?)

Thanx a Lot,
Peter

--
T: http://twitter.com/peter_shaw
F: http://facebook.com/PeterDunstonShaw
B: http://unthoughted.wordpress.com
V: 0177 3283056
.


_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Chris | 2 Mar 08:51 2012
Picon

Re: Write to Disk Performance - what is your opinion?

My take is that as a general policy, if you are doing serious audio 
recording, you shouldn't be running applications in the background 
which compete for your machine's resources. Just use it as an appliance 
and do your web surfing, whatever, on another machine.

-----Original Message-----
From: ynnhoj reim <johnmier182 <at> yahoo.com>
To: Portaudio Mailing List <portaudio <at> music.columbia.edu>
Sent: Thu, Mar 1, 2012 11:38 pm
Subject: Re: [Portaudio] Write to Disk Performance - what is your 
opinion?

hi pet

I think its a good idea to write every recorded buffer to disk to be 
able to save memory, because in the long run if you were running many 
applications that requires more memory that would be useful...

-john
Peter Shaw | 2 Mar 09:18 2012

Re: Write to Disk Performance - what is your opinion?

I agree! In my own studio there is no problem doing audio on dedicated maschines. But if you're writing
software and you want that many people use this piece, you have to deal with a lot of not so good setups and
acceptance. in the first place the Software have to do the job, After the First positiv touch you can
describe how to run ist better with some setup changes inside the docs.
After a download, you do not have a Long time to catch the user.

Maybe i've worked too Long in agencies :-)

pet

--
T: http://twitter.com/peter_shaw
F: http://facebook.com/PeterDunstonShaw
B: http://unthoughted.wordpress.com
V: 0177 3283056
.

On 02.03.2012, at 08:51, Chris <c319chris <at> aol.com> wrote:

> My take is that as a general policy, if you are doing serious audio recording, you shouldn't be running
applications in the background which compete for your machine's resources. Just use it as an appliance
and do your web surfing, whatever, on another machine.
> 
> 
> -----Original Message-----
> From: ynnhoj reim <johnmier182 <at> yahoo.com>
> To: Portaudio Mailing List <portaudio <at> music.columbia.edu>
> Sent: Thu, Mar 1, 2012 11:38 pm
> Subject: Re: [Portaudio] Write to Disk Performance - what is your opinion?
> 
> 
> 
> hi pet
> 
> 
> I think its a good idea to write every recorded buffer to disk to be able to save memory, because in the long
run if you were running many applications that requires more memory that would be useful...
> 
> 
> -john
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/portaudio
axintos.haase | 2 Mar 10:33 2012

Exception in pa_win_wmme.c, line 1936 (waveInClose) if running under debugger

Hello,

i'm using the current stable release (SVN rev 1788) as a DLL (+ cpp 
bindings as static lib) on Windows 7 SP1 x64, compiled using VS 2010 SP1.

If I run the debug build of my program (x86 or x64) under a debugger (CDB 
in QtCreator), an exception will occur at program shutdown in 
pa_win_wmme.c, line 1936:

 mmresult = waveInClose( ((HWAVEIN*)handlesAndBuffers->waveHandles)[i] );

The exception message is: Code 0xc0000005: read access violation at 0x0.

It will not occur if running without the debugger! In this case the 
program will exit cleanly (return code 0).

Is there anything I can do to make this little problem disappear ;) ?

Greetings,

M.

If you are not the intended addressee, please inform us immediately that you have received this e-mail in
error, and delete it. We thank you for your cooperation.  

Gmane