dan@image-line.com | 13 May 06:41 2015

wdmks hostapi bug?

Hello,

I'm currently investigating in WDM KS. I tried Portaudio yesterday, and  
would only be able to open one of the few KS devices listed by PA on my  
system.

While debugging, I found out that I had to add the following lines to  
PinInstantiate(PaWinWdmPin* pin) in pa_win_wdmks.c :

if (pin->frameSize==0)
{
	const int defaultNumFrames = 64; // also works with other values than 64
	pin->frameSize = defaultNumFrames *  
pin->ksDataFormatWfx->WaveFormatEx.wBitsPerSample/8 *  
pin->ksDataFormatWfx->WaveFormatEx.nChannels;
}

Just before the line:

return paNoError;

Otherwise the device won't work. The device is of type Type_kWaveRT. The  
line where it all goes wrong is:

result = PinGetBuffer(stream->render.pPin,  
(void**)&stream->render.hostBuffer, &dwRequestedSize, &bCallMemoryBarrier);

which calls function PinGetBufferWithoutNotification()

and fails in the line:
(Continue reading)

Rainer Schuetz | 12 May 14:23 2015
Picon

Using cmake/VS portaudio build in MinGW project

Dear list-members,

the subject basically says it. If possible I would like the cmake/VS build of portaudio in project that
needs to be built with MinGW. In MinGW the precompiled libraries used in builds have a ....dll.a
extension. Is there a way to create a library useable in a MinGW project (like the opposite of creating
import libs for use of mingw binary libs in VS projects)?

Thanks for any pointer
Best
Rainer
Stephane Poirier | 11 May 11:42 2015

Pa_Initialize() writing to console

Hi All,

Within a small windows application, when calling portaudio Pa_initialize()
I see a transient console window.

Is there a way to compile portaudio library so it does not do that?

Steph
Stephane Poirier | 11 May 11:36 2015

Input overflowed error message with Pa_ReadStream()

Hi All,

 From time to time, I am getting an "Input overflowed" error message 
when reading a stream using Pa_ReadStream(). What does this mean?

Steph
Rainer Schuetz | 5 May 18:47 2015
Picon

Inconvenience when compiling in msys2 with ASIO support

Hi,

just wanted to let you know, to a serious problem, but maybe something that can be enhanced? I am not even sure
if this is controled by the portaudio build configuration, but just in case:

Msys2 offers a nice way to build portaudio on Windows, it even offers binary 32- and 64-bit packages for
download via a package manager. Unfortunately they come without ASIO support, so if one needs it, one has
to build manually. This is made easy by a preconfigured package build script provided by msys2. By default
msys2 scripts build for 64 and for 32 bit in immediate succession, which can be useful. 

Unfortunately the build writes into the ASIOSDK2.3 folders and stores settings that conflict with
requirements of the second build for the other architecture, so the second build breaks. A case I found is a
folder .lib in ASIOSDK2.3/common. There must be more, as just removing that folder is not enough to let the
second build succeed. I work around by removing the old folder and extracting a fresh copy, but maybe the
portaudio build could be made not to write into the ASIO folder?

Best
Rainer
xprt | 1 May 21:27 2015
Picon

Portaudio, OSS and M Audio Delta1010LT big problem

Hello,
I can not use my 24 bit sound card named M Audio Delta 1010LT with Portaudio.
I have installed the latest version OSS sound drivers (v.4.2.2011) from 4Front Technologies - so I don't have ALSA.
Included example program - 'paex_pink' plays quasi noise for only few seconds but should take 1 minute.
The same behavior has Audacity  - sound editor - it plays whole any big file for seconds and RECORD is not possible.
Other applications that not use Portaudio work fine with my sound card (eg. ossrecord, XMMS, SOX).
I think there is a bug in Portaudio. What can I do to resolve this problem? Any help welcome.
Best regards.

Krzysztof



_______________________________________________
Portaudio mailing list
Portaudio <at> music.columbia.edu
http://music.columbia.edu/mailman/listinfo/portaudio
Alan Horstmann | 27 Apr 13:28 2015
Picon

Re: Pa_IsFormatSupported crasches in Debian

Hi Leif,

On Sunday 26 April 2015 23:07, you wrote:
On Saturday 25 April 2015 22:18, Alan Horstmann wrote:
< re alsa-info.sh >
> > Ah, OK.  Maybe try the upload option - it will put it somewhere and give
> > the link, I think?
>
> Hmmm, the VERY small test program I wrote crasches every time. On two
> different computers. As far as I can understand I am not doing anything
> unacceptable with the code (???)

The assert is in Alsa-lib; at this stage we're trying to narrow down what 
causes it, but I do suspect it is not in your code.  The Alsa-info will be 
important to take the issue to the Alsa-devel list.

> > > > I've gone ahead and done much of the work here myself by creating a
> > > > smallish test program
>
> > > I have run it and it does not generate any errors:
>
> > Interesting.  Did you try changing the num channels up to 6, as I can see
> > that is what your test program will be using, as it takes the max device
> > channels?
>
> No, but I changed my test program to never test more than 4 channels
> and that mafe no difference.

I think we need results for 2, 4, 6 channels with *both* test programs, 
otherwise they cannot be compared.  It may be that only stereo is working 
with 'front'?  The 2 test programs should produce the same result; if not, we 
need to investigate the difference as it may be significant.

> Did you try my little test program under Debian? (Probably needs
> an Intel soundcard to crasch.)

Unfortunately I have not had any Debian installation.  I am looking at doing 
so if necessary.  (BTW, in English the spelling is 'crash'.)

Regards

Alan
Alan Horstmann | 25 Apr 23:18 2015
Picon

Re: Pa_IsFormatSupported crasches in Debian

Hi Leif,

On Saturday 25 April 2015 01:58, Leif Asbrink wrote:
>
> > On Tuesday 21 April 2015 12:10, Alan Horstmann wrote:
> > > To track this down will require some further work.  Firstly, more info
> > > on the system.  Get the script from here:
> > >     http://www.alsa-project.org/alsa-info.sh
>
> My reply was stopped "Message body is too big: 87014 bytes
> with a limit of 20 KB" The output from
> http://www.alsa-project.org/alsa-info.sh
> was too big.

Ah, OK.  Maybe try the upload option - it will put it somewhere and give the 
link, I think?

> This is what I wrote:
> > Do you have a custom asoundrc?
>
> No.
>
> > Alongside the info, the
> > exact circumstances.  Eg, does this occur on the front device with just a
> > single attempt at 44100,
>
> Yes.
>
> > Ultimately a minimal test-case code that repeatedly demonstrates the
> > issue would be very valuable - perhaps a composite of bits of your code
> > and small bits of Portaudio_alsa - reduced by taking out anything that is
> > not necessary to show the problem.
>
> OK. Here is a test program of less than 100 lines that demonstrates the
> error:

Thanks, that is useful. <sniped>

> Look at the code. Half of it is overhead, this little program aborts
> every time - even if I change the order in which speeds are probed.
>
> > > Ultimately a minimal test-case code that repeatedly demonstrates the
> > > issue would be very valuable - perhaps a composite of bits of your code
> > > and small bits of Portaudio_alsa - reduced by taking out anything that
> > > is not necessary to show the problem.  I suspect it is the actions done
> > > in the pa_alsa function 'TestParameters()' that trigger this - indeed
> > > there is a comment there about assertions being hit.
>
> Well, I did that - plus the alsa-info.sh but did not make it through the
> moderator.

Yes, OK, that has caused me problems as well.  It is surprising sometimes how 
little can be posted - even portaudio.h is twice over the limit.  But I 
suppose given all the list archiving, it is reasonable to have quite a low 
limit.

> > I've gone ahead and done much of the work here myself by creating a
> > smallish test program (approx 300 lines, plus just portaudio.h) that can
> > be compiled and run on it's own.  I've attached a zip of test_format.c
> > with portaudio.h. The test format, channels and rates to be tested (an
> > array of sequential values) are all set with defines.  If we can mimic
> > the exact circumstances that cause the assert, and reproduce it, we have
> > a crude minimal demo program.  All the functions are copied from
> > pa_linux_alsa.c, with quick changes to minimise includes and unnecessary
> > functions.
>
> I have run it and it does not generate any errors:
>
> root <at> Xeon:/home/patest# ./test-format
> Testing rate: 22050
> AlsaOpen: Opening device front
> Result:....Invalid Sample Rate
> Testing rate: 32000
> AlsaOpen: Opening device front
> Result:....Invalid Sample Rate
> Testing rate: 44100
> AlsaOpen: Opening device front
> Result:....Success!!!
> Testing rate: 48000
> AlsaOpen: Opening device front
> Result:....Success!!!
> Testing rate: 96000
> AlsaOpen: Opening device front
> Result:....Success!!!

Interesting.  Did you try changing the num channels up to 6, as I can see that 
is what your test program will be using, as it takes the max device channels?

> root <at> Xeon:/home/patest#
>
> > I think you were using 6 channel output to 'front', Int16?  It would be
> > great if you cold compile and run this, with the correct parameters and
> > rates, and hopefully be able to reproduce the assert somehow?
>
> The very small program I wrote and again send to the list reproduces the
> assert every time. You can see in the code exactly what I did. I also tried
> to limit the number of channels to 4 in the case Portaudio would report
> more, but that made no difference. The purpose of the excercise is to make
> sure that no resampler will be invoked.

Perhaps try 2 channels here, also?

Regards

Alan
Ron | 25 Apr 22:13 2015
Picon

Raspberry Pi 2 / Raspbian / C-Media USB adapter

Hi

After much banging around due to my wealth if inexperience with Linux 
and in particular the sound subsystem I have finally narrowed down the 
area where an application that uses portaudio is failing. The 
application is failing with:

Expression 'parameters->channelCount <= maxChans' failed in 
'src/hostapi/alsa/pa_linux_alsa.c', line: 1438
Expression 'ValidateParameters( inputParameters, hostApi, 
StreamDirection_In )' failed in 'src/hostapi/alsa/pa_li
nux_alsa.c', line: 2742
pa19::start():  Invalid number of channels

The portaudio provided utility:  paqa_errs,  reports a similar error:

ron <at> squireoaksfarm-radio ~/src/portaudio/bin $ paqa_errs
Expression 'parameters->channelCount <= maxChans' failed in 
'src/hostapi/alsa/pa_linux_alsa.c', line: 1513
Expression 'ValidateParameters( inputParameters, hostApi, 
StreamDirection_In )' failed in 'src/hostapi/alsa/pa_linux_alsa.c', 
line: 2813
QA Report: 28 passed, 0 failed.

Is this due to the the fact the C-Media device is a mono-input?

-- 73 Ron / W4MMP
Stéphane Letz | 24 Apr 16:01 2015
Picon

ASIO driver in PortAudio access

Hi,

Ben Loftis (Ardour/Mixbus  on Windows ) describes the following solution for a recurring in problem on
ASIO/Windows: reading the available sample rates  opens the ASIO driver each time, which is somewhat slow
for some cards. 

Is the proposed solution possible ?

Stéphane 

Le 24 avr. 2015 à 15:51, Ben Loftis <ben <at> harrisonconsoles.com> a écrit :

> I think the first step is to get a flag into PortAudio which says "once you've opened an ASIO device,  don't
re-open the driver unless (a) you switch to a different device or  (b)  PortAudio is shut down.
> 
> In fact I don't think an exterior flag is necessary, but instead it should work this way all the time.
> 
> If we can't get that pushed into the mainline PortAudio, we can maintain a patch for Ardour/Mixbus.  But I
think it should be accepted into PA,  given that this flag exists on several commercial DAWs, and is
apparently needed for some devices.  Furthermore it "should" dramatically speed up the device setup on
some devices.
> 
> This way,  once you've opened an ASIO driver, you can query its supported sample rate without re-opening
the driver each time.
> 
> -Ben
Peter | 13 Apr 10:00 2015

Windows - ASIO4ALL

Hello,

I am Peter from BREAKOUTBOX, my website holds some PASCAL
example code for libsndfile, mpg123 and also PORTAUDIO
http://breakoutbox.de/pascal/pascal.html#PortAudio

Last month I started again working with PORTAUDIO,
I started improving my portaudio test application code
http://breakoutbox.de/software/portaudioplayer/portaudioplayer.html

As a Lazarus / Delphi (= Pascal) writer I am nearly unable
to compile the PORTAUDIO DLL myself. So I am always
happy to get a newer DLL version from someone else.


ISSUE:

All the actual Portaudio.dll files I was able to grab  do fail with ASOI4ALL.
The programs including the Portaudio.dll are (for example) :
- Sibelius (AVID)
- LMMS
- SqueezeLite

I tested the DLLs under Window 8.1 and Windows XP, same result.
With ASIO resp. the ASIO4ALL driver  my app stands still, no Audio.
When switching back to MME, DX or WDM-KS, my app plays again,
no problems. No need to restart my app. Only ASIO / ASIO4ALL fails to start.

"My" old Portaudio DLL v1899 is from 2010.
And this DLL works flawlessly with ASIO4ALL.
The DLL is included in the download of the "PortaudioPlayer".

There was a related thread also discussing this issue in 2013
http://music.columbia.edu/pipermail/portaudio/2013-November.txt


Any clues about why ASIO4ALL does not work anymore with Portaudio ?


Thanks,
Peter

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

Gmane