David Stuart | 1 Apr 16:31 2010

Re: DirectSound backend question


David Stuart wrote:
Ross Bencina wrote:
values and see what happens (DSSCL_NORMAL or DSSCL_PRIORITY). Let us know if that makes a difference. If so we can expose this as some kind of DS-specific user setting. What OS/DirectX version is your co-worker running?

Well he is actually using Win7-64bit. However, I have reproduced the same problem on WinXP-32bit.

I'm not yet 100% convinced this is the issue, but I'll let you know if it makes any difference.

Hi ..

As it turns out, DSSCL_EXCLUSIVE does not seem to be the problem. I have a feeling the term "exclusive" in this context does not really mean the same thing as it does with, say, WASAPI.

-- David Stuart, CounterPath Email: dstuart (at) counterpath (dot) com Phone: (613) 254-8886 x2234 Web: http://www.counterpath.com/ Address: 310 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5
_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Shawn O'Rourke | 1 Apr 17:51 2010

Link errors while building patest_sine.c

I downloaded a recent snapshot of PortAudio 19, and built it with Cygwin 
on Windows XP.  Then I tried to build the patest_sine.c example, and I 
got the following link errors:

g++ -c -I/usr/local/include patest_sine.c
g++ -o patest_sine -L/usr/local/lib -lportaudio  patest_sine.o
patest_sine.o:patest_sine.c:(.text+0x192): undefined reference to 
`_Pa_Initialize'
patest_sine.o:patest_sine.c:(.text+0x1a4): undefined reference to 
`_Pa_GetDefaultOutputDevice'
.

There were also several other undefined references.  I'm linking with 
libportaudio.a, so I'm guessing that I must be missing something else in 
my make file.

When I built the library, everything under the test directory built 
successfully, including patest_sine.c.  So I must have whatever I need 
to build it - I just can't figure out what's missing.  If someone can 
help, I would appreciated it.

Thanks,

Shawn
Matthew Robbetts | 4 Apr 04:25 2010
Picon

portaudio, LynxTWO-B and Linux/OSS

Hi all,

I'm writing an application to use Portaudio with a Lynx TWO-B sound
card. The only driver for this card under Linux is OSS. Now, I used this
card with Portaudio under Windows back in the day, with ASIO, and had no
problems. I'm looking to port that application to Linux.

Now, the problem: under Linux/OSS, this multichannel card is presented
as separate stereo inputs and stereo outputs. The internal hardware
mixer of the card can deal with 16 channels each of input and output, so
OSS presents it as 16 stereo pairs. My application (a loudspeaker
crossover processor) requires streaming from 2 inputs to 8 outputs. Can
you comment on the best way to achieve this with callback I/O in
portaudio, given the behaviour of the driver? IIRC the windows driver
for this card behaves similarly, but additionally presents a big
multichannel ASIO device, so I just used that in the old version.

I presume that blocking I/O might be applicable for this problem (I've
not used that before), but the callback method seems much neater and
more extensible, if I can somehow control this I/O with a single PA
stream. However, at the moment it looks like all I can do is open 5
separate stereo streams and have separate callbacks for each, which I
think would then need centralised buffering and manual synchronisation
between all the callbacks - not so neat anymore. Any ideas? I imagine
I've missed something silly.

Thanks,
Matthew Robbetts
Albert Santoni | 5 Apr 22:43 2010

Re: portaudio, LynxTWO-B and Linux/OSS

Hi Matthew,

On Sat, Apr 3, 2010 at 7:25 PM, Matthew Robbetts <wingfeathera <at> gmail.com> wrote:
> Hi all,
>
> I'm writing an application to use Portaudio with a Lynx TWO-B sound
> card. The only driver for this card under Linux is OSS. Now, I used this
> card with Portaudio under Windows back in the day, with ASIO, and had no
> problems. I'm looking to port that application to Linux.
>
> Now, the problem: under Linux/OSS, this multichannel card is presented
> as separate stereo inputs and stereo outputs. The internal hardware
> mixer of the card can deal with 16 channels each of input and output, so
> OSS presents it as 16 stereo pairs. My application (a loudspeaker
> crossover processor) requires streaming from 2 inputs to 8 outputs. Can
> you comment on the best way to achieve this with callback I/O in
> portaudio, given the behaviour of the driver? IIRC the windows driver
> for this card behaves similarly, but additionally presents a big
> multichannel ASIO device, so I just used that in the old version.
>
> I presume that blocking I/O might be applicable for this problem (I've
> not used that before), but the callback method seems much neater and
> more extensible, if I can somehow control this I/O with a single PA
> stream. However, at the moment it looks like all I can do is open 5
> separate stereo streams and have separate callbacks for each, which I
> think would then need centralised buffering and manual synchronisation
> between all the callbacks - not so neat anymore. Any ideas? I imagine
> I've missed something silly.

The recommended way to approach this would be to open a single stream,
which have your 5 stereo channel pairs interleaved, along with the two
input channels. When you're setting up your stream parameters, you can
specify how many output and input channels you want opened, so you
shouldn't have any problems there. You'll only have one callback
method too...

I've written code using PortAudio that handles all of this, and it
might be useful as an example for you:
http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/trunk/annotate/head:/mixxx/src/sounddeviceportaudio.cpp
Check out the SoundDevicePortAudio::open() function there, especially
lines 164-185 to see how I set up the stream parameters.

Good luck, and hope this helps,
Albert
Matthew Robbetts | 6 Apr 12:57 2010
Picon

Re: portaudio, LynxTWO-B and Linux/OSS

Hi Albert,

Thanks for your reply (and the link). I love neat code!

Now, there's a very good chance that I am being obtuse, so please bear
with me. However, I don't understand your answer. I know that you can
specify the desired number of channels when opening a stream by
setting PaStreamParameters.channelCount to the number of channels you
need. Pa_OpenStream() accepts a PaStreamParameters struct to detail
the stream inputs, and another one to detail the stream outputs. So,
when using Portaudio under Windows/ASIO, it was possible just specify
2 in this field of the `input' struct, 8 in this field of the `output'
struct, and open the one stream with a single call to Pa_OpenStream().

However, with Linux/OSS, my one multichannel sound card appears as 16
separate (stereo) devices to Portaudio. Trying to open more than 2
channels onto one of these devices doesn't work. If I understand it
correctly, your code receives in a single PaDeviceInfo, which in my
case would describe a single stereo device, so I can't see how this
problem is avoided.

Have I got it wrong?

Thanks a lot,
Matt

On 5 April 2010 21:43, Albert Santoni <alberts <at> mixxx.org> wrote:
> Hi Matthew,
>
> On Sat, Apr 3, 2010 at 7:25 PM, Matthew Robbetts <wingfeathera <at> gmail.com> wrote:
>> Hi all,
>>
>> I'm writing an application to use Portaudio with a Lynx TWO-B sound
>> card. The only driver for this card under Linux is OSS. Now, I used this
>> card with Portaudio under Windows back in the day, with ASIO, and had no
>> problems. I'm looking to port that application to Linux.
>>
>> Now, the problem: under Linux/OSS, this multichannel card is presented
>> as separate stereo inputs and stereo outputs. The internal hardware
>> mixer of the card can deal with 16 channels each of input and output, so
>> OSS presents it as 16 stereo pairs. My application (a loudspeaker
>> crossover processor) requires streaming from 2 inputs to 8 outputs. Can
>> you comment on the best way to achieve this with callback I/O in
>> portaudio, given the behaviour of the driver? IIRC the windows driver
>> for this card behaves similarly, but additionally presents a big
>> multichannel ASIO device, so I just used that in the old version.
>>
>> I presume that blocking I/O might be applicable for this problem (I've
>> not used that before), but the callback method seems much neater and
>> more extensible, if I can somehow control this I/O with a single PA
>> stream. However, at the moment it looks like all I can do is open 5
>> separate stereo streams and have separate callbacks for each, which I
>> think would then need centralised buffering and manual synchronisation
>> between all the callbacks - not so neat anymore. Any ideas? I imagine
>> I've missed something silly.
>
> The recommended way to approach this would be to open a single stream,
> which have your 5 stereo channel pairs interleaved, along with the two
> input channels. When you're setting up your stream parameters, you can
> specify how many output and input channels you want opened, so you
> shouldn't have any problems there. You'll only have one callback
> method too...
>
> I've written code using PortAudio that handles all of this, and it
> might be useful as an example for you:
> http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/trunk/annotate/head:/mixxx/src/sounddeviceportaudio.cpp
> Check out the SoundDevicePortAudio::open() function there, especially
> lines 164-185 to see how I set up the stream parameters.
>
> Good luck, and hope this helps,
> Albert
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/portaudio
>
Frank Lichtner | 6 Apr 16:13 2010
Picon

ASIO MinGW4.xxx

Hi to all,

I just joined the list so I don't know if this problem has been 
discussed before.

Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest 
from SVN, using MSYS to compile the provided makefile) ASIO is not 
working anymore. Pa_IsFormatSupported gives me always a 
paInvalidSampleRate error.

Any suggestions?

Frank
Ross Bencina | 7 Apr 06:47 2010

Re: ASIO MinGW4.xxx

Hi Frank

I guess it's this problem:
http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html

I'm not sure if Gary has resolved this in the mean time.

As far as I know no one has posted a fix.

Because ASIO uses the "thiscall" calling convention which is only supported 
by Microsoft compilers we use some assembley glue to invoke ASIO drivers 
when compiling with GCC. Apparrently the glue is not working for 
ASIOCanSampleRate() and ASIOSetSampleRate()

The glue is in IASIOThiscallResolver.cpp which contains extensive comments 
and explanation.

If I had gcc 3.x and 4.4 installed I'd dump the ASM for 
IASIOThiscallResolver::canSampleRate and 
IASIOThiscallResolver::setSampleRate calls in both compiler versions and see 
what's changed. Then work out how to fix CALL_THISCALL_1_DOUBLE to generate 
the same code in both compilers.

Ross.

===================================
Perform, Compose, Mangle
AudioMulch 2.0 modular audio software for PC and Mac
http://www.audiomulch.com
----- Original Message ----- 
From: "Frank Lichtner" <Frank <at> Lichtner.de>
To: "PortAudio" <portaudio <at> music.columbia.edu>
Sent: Wednesday, April 07, 2010 12:13 AM
Subject: [Portaudio] ASIO MinGW4.xxx

> Hi to all,
>
> I just joined the list so I don't know if this problem has been
> discussed before.
>
> Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest
> from SVN, using MSYS to compile the provided makefile) ASIO is not
> working anymore. Pa_IsFormatSupported gives me always a
> paInvalidSampleRate error.
>
> Any suggestions?
>
> Frank
>
> _______________________________________________
> Portaudio mailing list
> Portaudio <at> music.columbia.edu
> http://music.columbia.edu/mailman/listinfo/portaudio 
Gary Scavone | 7 Apr 15:58 2010
Picon

Re: ASIO MinGW4.xxx

Nope ... I never had time to investigate further.

--gary

On 2010-04-07, at 12:47 AM, Ross Bencina wrote:

> Hi Frank
> 
> I guess it's this problem:
> http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html
> 
> I'm not sure if Gary has resolved this in the mean time.
> 
> As far as I know no one has posted a fix.
> 
> Because ASIO uses the "thiscall" calling convention which is only supported by Microsoft compilers we
use some assembley glue to invoke ASIO drivers when compiling with GCC. Apparrently the glue is not
working for ASIOCanSampleRate() and ASIOSetSampleRate()
> 
> The glue is in IASIOThiscallResolver.cpp which contains extensive comments and explanation.
> 
> If I had gcc 3.x and 4.4 installed I'd dump the ASM for IASIOThiscallResolver::canSampleRate and
IASIOThiscallResolver::setSampleRate calls in both compiler versions and see what's changed. Then
work out how to fix CALL_THISCALL_1_DOUBLE to generate the same code in both compilers.
> 
> Ross.
> 
> 
> 
> 
> 
> ===================================
> Perform, Compose, Mangle
> AudioMulch 2.0 modular audio software for PC and Mac
> http://www.audiomulch.com
> ----- Original Message ----- From: "Frank Lichtner" <Frank <at> Lichtner.de>
> To: "PortAudio" <portaudio <at> music.columbia.edu>
> Sent: Wednesday, April 07, 2010 12:13 AM
> Subject: [Portaudio] ASIO MinGW4.xxx
> 
> 
>> Hi to all,
>> 
>> I just joined the list so I don't know if this problem has been
>> discussed before.
>> 
>> Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest
>> from SVN, using MSYS to compile the provided makefile) ASIO is not
>> working anymore. Pa_IsFormatSupported gives me always a
>> paInvalidSampleRate error.
>> 
>> Any suggestions?
>> 
>> Frank
>> 
>> _______________________________________________
>> 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
> 
TJF | 7 Apr 16:35 2010
Picon

Read entire file to memory

Hi,

would be nice, if anyone would have an idea for my problem - even when 
it is on RtAudio. The problem would be very similar in Portaudio.

I want to read an entire raw-file to memory. But I cannot find a working 
output function to play the allocated buffer...

Thanks a lot.
Regards
Thomas

That's what I have (s.b. the normal working code):

typedef signed short  MY_TYPE;
#define FORMAT RTAUDIO_SINT16 // 16 bit
#define SCALE  32767.0

// OutputData struct:
struct OutputData {
  FILE *fd;
  unsigned int channels;
  unsigned int size;
  size_t length;
  void *buffer;
  unsigned int position;
};

//Callback:
int output( void *outputBuffer, void *inputBuffer, unsigned int 
nBufferFrames,
            double streamTime, RtAudioStreamStatus status, void *data )
{
  unsigned int i;
  OutputData *oData = (OutputData*) data;
  MY_TYPE *out = (MY_TYPE *)outputBuffer;
  MY_TYPE *buf = &((MY_TYPE *)oData->buffer)[oData->position];
  for (i=0; i < nBufferFrames; i++) {
    if (oData->position < oData->length) {
        *out++ = *buf++;
        ++oData->position;
    } else
        *out++ = 0;
  }
  return (oData->position >= oData->length);
}

// data struct...
   OutputData data;
   data.fd = fopen ( file , "rb" );
   std::cout << "\ndata.fd " << data.fd << std::endl;
   if (data.fd == NULL) {
       std::cout << "Unable to find or open file!\n";
       exit (1);
   }
   fseek (data.fd , 0 , SEEK_END);
   data.size = ftell (data.fd);
   std::cout << "\ndata.size:  " << data.size << std::endl;
   data.buffer = calloc (data.size,1);
   if (data.buffer == NULL) {
       std::cout << "Memory error!\n";
       exit (2);
   }
   fseek (data.fd , 0 , SEEK_SET);
   data.length = fread (data.buffer,1,data.size,data.fd);
   // :2 (channels) , :2(bytes/Sample), :2 (1 Frame= 2 Samples)
   //data.length = data.length/8;
   /*
   if (data.length != data.size) {
       std::cout << "Reading error!\n";
       exit (3);
   }
   */

 // This is the "normal" working code: 
------------------------------------------------

 // OutputData struct:
struct OutputData {
  FILE *fd;
  unsigned int channels;
};

 //... callback:
 int output( void *outputBuffer, void *inputBuffer, unsigned int 
nBufferFrames,
            double streamTime, RtAudioStreamStatus status, void *data )

{
  unsigned int data.count = fread( outputBuffer, oData->channels * 
sizeof( MY_TYPE ), nBufferFrames, oData->fd);
  if ( count < nBufferFrames ) {
    unsigned int bytes = (nBufferFrames - data.count) * oData->channels 
* sizeof( MY_TYPE );
    unsigned int startByte = data.count * oData->channels * sizeof( 
MY_TYPE );
    memset( (char *)(outputBuffer)+startByte, 0, bytes );
    return 1;
  }
  return 0;
}

// data struct...
   OutputData data;
   data.fd = fopen ( file , "rb" );
Dmitry Kostjuchenko | 7 Apr 19:59 2010
Picon

Re: ASIO MinGW4.xxx

Hi Guys!

Well, I can confirm that MinGW (GCC 4.4.0, 32-bit) is working ok with ASIO. GCC ABI will not change for WIN32 model thus if ASM thiscall resolver was working with 3.x then it will be working with any other WIN32 compatible version of GCC. asiothiscallresolver.cpp is included in configure.in and was compiled I guess.

To debug the problem you could install ASIO4ALL driver and try PA through it, if it works (in case you are sure that parameters you pass to Pa_IsFormatSupported are 100% correct) then it is a problem of your ASIO drivers may be.

Dmitry.

Quoting Gary Scavone <gary.scavone <at> mcgill.ca>:
Nope ... I never had time to investigate further.

--gary

On 2010-04-07, at 12:47 AM, Ross Bencina wrote:

Hi Frank

I guess it's this problem:
http://music.columbia.edu/pipermail/portaudio/2010-January/009847.html

I'm not sure if Gary has resolved this in the mean time.

As far as I know no one has posted a fix.

Because ASIO uses the "thiscall" calling convention which is only supported by Microsoft compilers we use some assembley glue to invoke ASIO drivers when compiling with GCC. Apparrently the glue is not working for ASIOCanSampleRate() and ASIOSetSampleRate()

The glue is in IASIOThiscallResolver.cpp which contains extensive comments and explanation.

If I had gcc 3.x and 4.4 installed I'd dump the ASM for IASIOThiscallResolver::canSampleRate and IASIOThiscallResolver::setSampleRate calls in both compiler versions and see what's changed. Then work out how to fix CALL_THISCALL_1_DOUBLE to generate the same code in both compilers.

Ross.





===================================
Perform, Compose, Mangle
AudioMulch 2.0 modular audio software for PC and Mac
http://www.audiomulch.com
----- Original Message ----- From: "Frank Lichtner"
To: "PortAudio"
Sent: Wednesday, April 07, 2010 12:13 AM
Subject: [Portaudio] ASIO MinGW4.xxx


Hi to all,

I just joined the list so I don't know if this problem has been
discussed before.

Since I moved from MinGW 3.4.5 to MinGW 4.4.x to build portaudio (latest
from SVN, using MSYS to compile the provided makefile) ASIO is not
working anymore. Pa_IsFormatSupported gives me always a
paInvalidSampleRate error.

Any suggestions?

Frank

_______________________________________________
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


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



iAuxSoft
------------------
[www.iauxsoft.com]
_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio

Gmane