headers
Ross Bencina | 1 Mar 2008 01:06
Favicon

Re: checked in new ASIO blocking i/o implementation

Many thanks Peter

I've checked in your patches and also updated the VC6 .dsp file...

I notice that /configure is out of date. I guess this can be updated once 
the other patches you're working on are stabilised...

> It's a little odd that the build system was left in a broken state.

Sorry, it was an odd day and I'd been sitting on Sven's critical patch for a 
week already.

If only it was "the build system" :-) we have quite a few you know... (and 
this is not directed at anyone in particular) I don't feel it's reasonable 
to expect developers to have to deal with N different build systems just to 
commit an update to the sourcecode. Perhaps going forward if we just had a 
rule "don't break configure" that would be enough and maintainers of the 
other build systems would at least know where to pick up changes -- only 
problem with that is that not everyone uses configure / can test it. argh.

There are still some things which are presumably broken, and some that were 
already broken. I'm not suggesting you fix these, just noting it for now in 
case someone is able to update/test these easily, if not I'll make a Trac 
ticket:

> File bindings\cpp\build\vc6\devs_example.dsp:
> SOURCE=..\..\..\..\pa_asio\pa_asio.cpp
> File bindings\cpp\build\vc6\sine_example.dsp:
> SOURCE=..\..\..\..\pa_asio\pa_asio.cpp
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ross Bencina | 1 Mar 2008 01:44
Favicon

Re: Moderation

Thanks Magnus

I've checked in your patch, looks good:
http://www.portaudio.com/trac/changeset/1368#file1

I thing these changes are worth having irrespective of ticket 49
"Default device is paNoDevice if the Default API contains no devices."
http://www.portaudio.com/trac/ticket/49

Also added a note to ticket 61 about the technique you used for dealing with 
NULL returns from Pa_GetDeviceInfo:
"tests don't check for NULL return value of Pa_GetDeviceInfo()"
http://www.portaudio.com/trac/ticket/61

Will sort out your Trac account presently.

Best wishes

Ross.

----- Original Message ----- 
From: "Magnus Jonsson" <magnus <at> smartelectronix.com>
To: "Ross Bencina" <rossb-lists <at> audiomulch.com>
Sent: Friday, February 29, 2008 2:58 PM
Subject: Re: [Portaudio] Moderation

> Hi Ross,
>
> I don't have any specific plans to work on PortAudio in the long term, but
> on the other hand, PA is not working on my Linux/PPC system so I am
(Continue reading)

Permalink | Reply | 0 comments |
headers
avi daya | 1 Mar 2008 23:24
Picon

(no subject)

_______________________________________________
Portaudio mailing list
Portaudio <at> techweb.rfa.org
http://techweb.rfa.org/mailman/listinfo/portaudio
Permalink | Reply | 0 comments |
headers
Bob McGwier | 2 Mar 2008 12:47
Picon

Mingw/Msys

I svn updated my repository and ran configure; make; make install; under 
MinGW and Msys.

I did not attempt to add any support for any host except what comes 
natively.

pa_devs recognized all of my mme devices and lots of the tests worked, I 
did not run an exhaustive test but it compiles, installs, and runs many 
of the tests..

Bob
Permalink | Reply | 0 comments |
headers
Ian Brown | 3 Mar 2008 12:35
Picon

Cannot hear PortAudio recorded file

Hello,

I am using the stable_v19_20071207 version of PortAudio on Linux.

 I am trying to test portaudio. I tried recording to a file using the
 portaudio/test/patest_record.c example.
 I used the example as it is  (just enabled the recording by
  uncommenting the "#if 0" block in main()).
 Now, I had built and ran patest_record.
 A file named "recorded.raw" was geneated.
 I want to check and hear this file. I tried to hear it using
 Audacity (I am working on Linux, I must add). I tried various
 formats in "import raw" in Audacity but I cannot hear something correctly.

 Is it possible to hear the recoreded file in Linux ?
 Is it possible to hear the recoreded file with Audacity in Linux ?
 If so - what format should I choose for "import raw" in Audacity?

Any help will be appreciated,

Regards,
Ian
Permalink | Reply | 3 comments |
headers
Jonathan Addleman | 3 Mar 2008 15:03
Picon

Re: Cannot hear PortAudio recorded file

Ian Brown wrote:
> Hello,
> 
> I am using the stable_v19_20071207 version of PortAudio on Linux.
> 
>  I am trying to test portaudio. I tried recording to a file using the
>  portaudio/test/patest_record.c example.
>  I used the example as it is  (just enabled the recording by
>   uncommenting the "#if 0" block in main()).
>  Now, I had built and ran patest_record.
>  A file named "recorded.raw" was geneated.
>  I want to check and hear this file. I tried to hear it using
>  Audacity (I am working on Linux, I must add). I tried various
>  formats in "import raw" in Audacity but I cannot hear something correctly.

quickest and easiest way to listen is probably to convert that raw audio
data into a wave file using sox (available in every distro if you don't
have it installed already).

sox -r 44100 -4 -c2 -f recorded.raw -w bla.wav

(that's assuming you used the default setup in patest_record, and didn't
change the sample format or anything.)

You can probably do the same thing with audacity. The raw is saved as
32-bit floating-point, 2 channel audio at 44100 samples per second.

--

-- 
Jon-o Addleman - http://www.redowl.ca
Permalink | Reply | 0 comments |
headers
AudioMulch Sales (Ross Bencina | 1 Mar 2008 01:15
Favicon

Re: PortAudio ALSA Realtime Patch

Hi Guys

wrt the real-time scheduling thing my suggestion would be to investigate 
what is considered standard policy. Arve has already noted that rt 
scheduling is an option for Jack, not a default, but what about other apps?

We had a related situation on Windows a few years back and ended up removing 
the option for RT priorities altogether because it caused too many system 
conflicts, not sure if that would happen on Linux though.

In any case, it seems to me that end-users would want to have the option to 
make a choice (whether or not it's the default within PA) so the PA default 
is less important than providing a method to enable it or disable it, which 
I understand we already have. MIXXX can always choose to default to having 
it switched on.

I think the availability of host-api-specific extensions is a separate issue 
and should be treated as such. Isn't there a standard way to _try_ to load a 
specific function from a shared library at runtime on Linux?

Ross.

----- Original Message ----- 
From: "Albert Santoni" <asantoni <at> uwo.ca>
To: "Arve Knudsen" <aknuds-1 <at> broadpark.no>
Cc: "mixxx-devel" <mixxx-devel <at> lists.sourceforge.net>; "portaudio" 
<portaudio <at> techweb.rfa.org>
Sent: Saturday, March 01, 2008 7:24 AM
Subject: Re: [Portaudio] PortAudio ALSA Realtime Patch

> Hi Arve,
>
> Thanks for your attention on this, replies inline below:
>
> On 28-Feb-08, at 4:17 PM, Arve Knudsen wrote:
>
>> Hello Albert
>>
>> On Fri, 22 Feb 2008 05:32:01 +0100, Albert Santoni <asantoni <at> uwo.ca> 
>> wrote:
>>
>>> Hi all,
>>>
>>> A while ago I mentioned that the host-api specific extensions in
>>> PortAudio aren't usable on Linux because applications will fail to  link
>>> against the extensions' symbols (they're not exported for some  reason).
>>> Specifically, I was interested in using the
>>> PaAlsa_EnableRealtimeScheduling() extension to improve Mixxx's
>>> performance with ALSA, which is noticeably worse than when using OSS
>>> (higher latency needed with ALSA).
>>>
>>> Rather than sort out the exporting-symbols-properly mess (it's  beyond 
>>> my
>>> capacity at the moment), I'd like to propose just enabling realtime
>>> scheduling by default in the StartStream implementation for ALSA.
>>> Attached is a simple patch to do so.
>>>
>>> Two questions to go along with the patch:
>>> - Is there a good reason not to enable RT by default?
>>
>> It is for conservative reasons. The PA thread will attain RT  privileges, 
>> at the expense of other threads/processes. I'm not sure  it's a good idea 
>> to always enable this. I don't think it's common  practice, for instance 
>> the JACK server has an option to turn on  realtime scheduling.
>>
>
> I'm on the other side of the fence with this one. Of the developers  using 
> the non-blocking API, I think the vast majority of them want  realtime 
> operation. There's no point in getting underruns in your  audio. And when 
> our users run RT kernels, they expect applications to  take advantage of 
> that.
>
>
>>> - I'm just assuming that this will fail gracefully/silently if RT
>>> scheduling is not available. Can anyone confirm this?
>>
>> Depends what you mean by not available? If it's not permitted, the 
>> operation will fail gracefully. Otherwise, paInternalError is  returned.
>
> Ok, so I don't think there's any problem then. RT kernel users will  get 
> lower latencies, and it won't make a difference for everyone else.  If 
> you've got a realtime audio API, you might as well make the  defaults 
> "realtime". :)
>
> Anyone else have any thoughts?
>
> Thanks,
> Albert
>
>
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> techweb.rfa.org
> http://techweb.rfa.org/mailman/listinfo/portaudio
>
Permalink | Reply | 1 comment |
headers
Arve Knudsen | 3 Mar 2008 23:42
Picon
Favicon

Re: portaudio stops working, but query fixes it

Hi Mads

I have no idea what's going on here. It is possible that opening the  
device in different configurations makes it work again somehow. You could  
try aplay, with the same samplerate as patest_pink (44100kHz), instead of  
patest_pink and see if that is also muted. If you get muted output from  
aplay as well, the problem is not within PortAudio.

Arve

On Sun, 10 Feb 2008 18:47:35 +0100, Mads Dyrholm <mistermads <at> gmail.com>  
wrote:

> Hello,  I have experienced something weird.
>
> First, I boot my machine (Ubuntu) and everything works fine.  
> ./patest_pink
> makes some noise in my default output.
>
> Then, if I listen to a soundfile, or if Firefox makes a sound due to,  
> say,
> gmail chat incoming message, then suddenly ./patest_pink does not work
> anymore. No error message, simply silence.
>
> But, then if I run ./pa_devs ... then suddenly ./patest_pink starts to  
> work
> again.
>
> I looked at the output of ./pa_devs before and after the firefox step  
> above.
> And the output is identical.
>
> Is it possible that ./pa_devs does something useful besides the query? (I
> guess it must, but what?)
>
> regards
>   Mads
Permalink | Reply | 0 comments |
headers
Arve Knudsen | 3 Mar 2008 23:49
Picon
Favicon

Re: Cannot hear PortAudio recorded file

Hi Ian

On Mon, 03 Mar 2008 12:35:14 +0100, Ian Brown <ianbrn <at> gmail.com> wrote:

> Hello,
>
> I am using the stable_v19_20071207 version of PortAudio on Linux.
>
>  I am trying to test portaudio. I tried recording to a file using the
>  portaudio/test/patest_record.c example.
>  I used the example as it is  (just enabled the recording by
>   uncommenting the "#if 0" block in main()).
>  Now, I had built and ran patest_record.
>  A file named "recorded.raw" was geneated.
>  I want to check and hear this file. I tried to hear it using
>  Audacity (I am working on Linux, I must add). I tried various
>  formats in "import raw" in Audacity but I cannot hear something  
> correctly.
>
>  Is it possible to hear the recoreded file in Linux ?
>  Is it possible to hear the recoreded file with Audacity in Linux ?
>  If so - what format should I choose for "import raw" in Audacity?
>
> Any help will be appreciated,

The recorded data should be interleaved stereo, 44100 samples a second. If  
you're not able to play it back correctly in Audacity, I'd suggest asking  
someone familiar with that program.

Arve
Permalink | Reply | 1 comment |
headers
Bob McGwier | 3 Mar 2008 23:50
Picon

Cygwin

The trac page instructions for cygwin make of a native library fail on 
my cygwin installation fails as follows:

> bash-3.2$ ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin 
> CC='gcc -mno-cygwin' host_alias=i686-pc-mingw32
> checking for i686-pc-mingw32-gcc... gcc -mno-cygwin
> checking for C compiler default output file name... a.exe
> checking whether the C compiler works... yes
> checking whether we are cross compiling... yes
> checking for suffix of executables... .exe
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc -mno-cygwin accepts -g... yes
> checking for gcc -mno-cygwin option to accept ISO C89... none needed
> configure: error: cannot find install-sh or install.sh in "." "./.." 
> "./../.."
> bash-3.2$

Bob
Permalink | Reply | 501 comments |

Gmane