headers
Ross Bencina | 1 Nov 2011 04:30
Favicon

Re: Mingw32/msys compile problem

Hello Norbert

Can you please confirm what version of PA you are trying to build?

You would be well advised to use the most recent stable snapshot or the 
nightly tarball.

Thanks

Ross.

On 1/11/2011 10:29 AM, Norbert Varga wrote:
> Hello,
>
> I have a problem compiling Portaudio under Win7/mingw32/msys. Gcc says
> no input files after ./configure&&  make. Screenshot:
> http://w2.nonoo.hu/portaudioproblem.png
>
> Could someone help me please?
>
> --
> Norbert Varga
> http://www.nonoo.hu/
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/portaudio
>
Permalink | Reply | 1 comment |
headers
Ross Bencina | 1 Nov 2011 04:36
Favicon

Re: Portaudio, Java Native (JNI) and latency

Hello Axel

It can take a long time to start and stop a stream. Some host APIs have 
to allocate a lot of resources to get things going.

For this reason you should keep a stream open and build an engine that 
always outputs audio (even if silence) and processes messages from your 
JNI thread to play samples.

The usual thing would be to set up a lock free queue for commands. The 
PA audio callback reads commands and executes them (eg schedules audio 
buffers for playback/mixing). The JNI code would just enqueue messages 
at the other end. One issue is managing all the buffers and making sure 
they are freed at the appropriate times.

You can use pa_ringbuffer.c as a message queue.

You havn't said if Java will load the audio data from disk into 
in-memory buffers or if you expect to stream it on the fly.

All this might be a bit to get your head around if you've never done it 
before so expect to spend some time on it.

Ross.

On 1/11/2011 9:31 AM, Axel Burandt-van Schoor wrote:
> Hello collegues,
> Im currently trying to implement a sampler using JNI interface and
> portaudio.
> Samples will be managed within the JAVA implementation. Samples provided
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ross Bencina | 1 Nov 2011 04:49
Favicon

Re: build problem (Win/ASIO/Mingw)

Hi Alex

On 1/11/2011 8:10 AM, Alexander Carôt wrote:
> src/hostapi/asio/pa_asio.cpp:104:33: error: pa_win_coinitialize.h: No such
> file or directory

that's in src/os/win

which needs to be set as an include directory.

A quick hack would be to move pa_win_coinitialize.h to /include

I think the correct fix reqires more changes to configure.in (adding 
that path as an include path to all host APIs that use 
pa_win_coinitialize). Looking at the current code in configure.in I am 
reluctant to change it without knowing who is building what.

 <at> Alex: you're only building for ASIO is that correct?

 <at> Ralphy: what Host APIs are you compiling for?

Ross.
Permalink | Reply | 2 comments |
headers
Alexander Carôt | 1 Nov 2011 07:04
Picon

Re: build problem (Win/ASIO/Mingw)

Hej Ross,

> A quick hack would be to move pa_win_coinitialize.h to /include

Will do so if I can find some time in between.

> 
> I think the correct fix reqires more changes to configure.in (adding 
> that path as an include path to all host APIs that use 
> pa_win_coinitialize).

Yepp, it looks like that. As usual a change leads to other problems/changes ;-)

>  <at> Alex: you're only building for ASIO is that correct?

Yes. Configure looks like this: ./configure --with-winapi=asip --with-asiodir=../ASIOSDK2

All the best

Alex

 
--

-- 
http://www.carot.de
http://www.triologue.de
Email : Alexander <at> Carot.de
Tel.: +49 (0)177 5719797

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone
(Continue reading)

Permalink | Reply | 0 comments |
headers
Norbert Varga | 1 Nov 2011 09:37
Picon
Gravatar

Re: Mingw32/msys compile problem

I've tried with pa_stable_candidate_v19_20111026.tgz and now with the
latest snapshot (Monday, 31-Oct-2011 21:37:15 PDT), problem is the
same.

--
Norbert Varga
http://www.nonoo.hu/

On Tue, Nov 1, 2011 at 04:30, Ross Bencina <rossb-lists <at> audiomulch.com> wrote:
> Hello Norbert
>
> Can you please confirm what version of PA you are trying to build?
>
> You would be well advised to use the most recent stable snapshot or the
> nightly tarball.
>
> Thanks
>
> Ross.
>
>
> On 1/11/2011 10:29 AM, Norbert Varga wrote:
>>
>> Hello,
>>
>> I have a problem compiling Portaudio under Win7/mingw32/msys. Gcc says
>> no input files after ./configure&&  make. Screenshot:
>> http://w2.nonoo.hu/portaudioproblem.png
>>
>> Could someone help me please?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Horstmann | 1 Nov 2011 13:16
Picon

Re: [Linux] Stuttering with Default device

On Monday 31 October 2011 03:40, Ross Bencina wrote:
> On 30/10/2011 8:14 AM, Alan Horstmann wrote:
> > My further tests now show that using minlat, at 'latency request' 2352
> > Alsa is configured with 3 periods, but at 2351 it changes to 2 periods. 
> > Why, and the significance, is discussed below...
>
> I'm not really clear on what the units of 2352 is.

Just the number typed into the running minlat as with the un-modified version 
- that is requested latency in frames?

> My understaning is that "period" means "buffer" so 2 periods is double
> buffering, 3 periods is triple buffering, is that correct?

Alsa tends to define it as the interval between interrupts/notifications to 
the application.  The ringbuffer provided is a multiple of the period size.  
Different hardware may work in various ways internally but ultimately it 
plays out of the buffer while the app fills it.  The Alsa host buffer is 
always the whole thing; the period is the working chunk (which often seems to 
be referred to in Portaudio as one buffer of several?).

> >>   >  'default' uses dmix at 48000 and converts for other rates, and I
> >>   >  think this is confusing the Pa configuration, perhaps.
> >>
> >> PA probably returns the same default latencies for all ALSA devices.
> >> Perhaps PA should be returning higher values for dmix?

<snip>
> It sounds like ALSA has at least 3 "layers": (1) direct hardware, (2)
> "plugin" layerd on hardware to support SRC and format conversion, (3)
(Continue reading)

Permalink | Reply | 23 comments |
headers
Axel Burandt-van Schoor | 1 Nov 2011 13:54
Picon
Picon

Re: Portaudio, Java Native (JNI) and latency

Hello Ross,

thanks a lot for your hint,

I already had a suspect in this direction, but as a beginner in audio
programming I was not encouraged enough to step further after a lot of 
frustration :)

So I will try to hold some streams open. However there is another problem 
which
I not yet see to solve: The samples have to be pitched by -100 to 100 cent, 
where the
amount of the pitch can not be determined in advance but is known nut until 
on trigger of the MIDI noteON.
Currently Im solving this by in/decreasing the samplerate when opening the 
stream.
For this reason I have opened the stream with the appropriate rate on an 
incomming noteOn event
and not before. Do you have any idea to circumvent this and to switch the 
rate e.g. of a stream already opened?

Best regards for your hints

Axel

----- Original Message ----- 
From: "Ross Bencina" <rossb-lists <at> audiomulch.com>
To: "Portaudio Mailing List" <portaudio <at> music.columbia.edu>
Sent: Tuesday, November 01, 2011 4:36 AM
Subject: Re: [Portaudio] Portaudio, Java Native (JNI) and latency
(Continue reading)

Permalink | Reply | 1 comment |
headers
Phil Burk | 1 Nov 2011 16:24

Re: Portaudio, Java Native (JNI) and latency

Hello Axel,

On 11/1/11 5:54 AM, Axel Burandt-van Schoor wrote:
> The samples have to be pitched by -100 to 100 cent, where the amount
> of the pitch can not be determined in advance but is known nut until
> on trigger of the MIDI noteON. Currently Im solving this by
> in/decreasing the samplerate when opening the stream.

That is not always possible. Often the hardware will only play at fixed 
rates, such as 44100 and 48000.  Also it will not work if you want to 
play multiple samples simultaneously or to do filtering or effects after 
pitch shifting the samples.

If you want to implement a sampler or a synthesizer then you will need 
to just open an audio stream once and leave it open. Then do all your 
starting and stopping of samples, and sample rate conversion, effects 
processing and mixing using math in your synthesizer. Keep the audio 
stream running and just output zeros if there are no samples to play.

To rate convert your samples, just start with a linear interpolation 
between samples. Mathematicians will cringe but it will get you going 
and not sound too bad. Then if you have time use a better multi-point 
interpolator.

(BTW, if you are interested in Java based synthesis and sampling then 
check out JSyn at www.softsynth.com/jsyn". Send questions about JSyn to 
the JSyn list, not here.)

Phil Burk
(Continue reading)

Permalink | Reply | 0 comments |
headers
Victor Lazzarini | 2 Nov 2011 01:31
Picon
Favicon

platform support

HI everyone,

at the risk of being completely ignored again, I would like to ask the  
portaudio developers if they are have/are considering support for
OpenSL ES. The reason is that I do not want to reinvent the wheel as  
we have a perfectly working portaudio module and if the support is  
there, we'll just build it.
Otherwise, I will write new code.

Regards

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie
Permalink | Reply | 2 comments |
headers
Ross Bencina | 2 Nov 2011 06:52
Favicon

Re: platform support

Hi Victor

On 2/11/2011 11:31 AM, Victor Lazzarini wrote:
> at the risk of being completely ignored again

Not sure when that was. I suspect you were overlooked rather than 
ignored, in my case at least.

 > I would like to ask the
> portaudio developers if they are have/are considering support for
> OpenSL ES.

There is a ticket in trac for doing an Android version of PortAudio. 
It's been discussed. As afar as I know there has been no active work on 
this -- maybe someone has experimented privately?

I fully encouage anyone who would like to develop an OpenSL ES version 
of PortAudio (or a RemoteIO version, or any other interface for that 
matter).

> The reason is that I do not want to reinvent the wheel as we
> have a perfectly working portaudio module and if the support is there,
> we'll just build it.
> Otherwise, I will write new code.

I would love to see Android/OpenSL ES support in PortAudio.

Ross
Permalink | Reply | 1 comment |

Gmane