headers
Tatu Portin | 1 Aug 2010 16:27
Picon

Input buffer does not work properly for 8-bit samples

Note: I am using pa_snapshot.tgz, created on 2010-07-19, 10:59:15

I am testing patest_record.c that comes with portaudio library.
 * $Id: patest_record.c 1368 2008-03-01 00:38:27Z rossb $
Well, when using PA_SAMPLE_TYPE as paFloat32 or paInt16, sound input
works as expected. Thou, calculating differences between samples,
I noticed that there is only 255 different values, that means
my sound card input is only 8-bit. Well, but when I enable
PA_SAMPLE_TYPE paInt8 instead, I get no input at all..
it doesn't write anything to the buffer but zeros.

Compiler is mingw32-gcc version 4.4.0.

Soundcard is SoundMAX Digital Audio (integrated), and I'm using WaveOut
Mix as capture device. That means input is anything that gets played on
the computer. This works ok, but using 8-bit samples, I get no input
but zeros.

Tatu Portin.
Permalink | Reply | 0 comments |
headers
Bill Good | 2 Aug 2010 01:53
Picon

Fwd: Fwd: Updated PortAudio package for Ubuntu(Needtesters!)

> Dmitry Kostjuchenko dmitrykos at iauxsoft.com 
> Fri Jul 30 08:57:28 EDT 2010
> In addition to my prev. message:
> 
> I managed to test my last commit on real Ubuntu x64 and for me all works ok. 
> I tested sample rates: 44.1k, 48k, 96k and 192k, used different latencies, 
> managed to go down to 1.15ms. The device was not-mmaped and on Ubuntu x86 
> (in VirtualBox) mmaped. New changes seem to be working.
> 
> Awaiting for your tests to see if this issue could be closed.
> 
> Regards,
> Dmitry.

Hi Dmitry,
I'm still encountering the error in r1532, here's a log with the errors I'm 
getting, it also has the values being passed to Pa_OpenStream. Strangely, I'm 
only having issues with the "default" ALSA device (connecting directly to my 
sound card works at all settings), and it seems to work at 2048 frames per 
buffer (~21 ms latency) 1024 frames/buffer (~10 ms) but not at any of the other 
values (higher and lower) I tried.

Also -- sorry for the horrible quoting job, I didn't get this in email so I 
had to paste it from the web.

Thanks for looking in to this!
Bill

Log:
Debug: [Main]: SoundDevicePortAudio::open() "12, default"
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dmitry Kostjuchenko | 2 Aug 2010 08:41
Favicon

Re: Fwd: Fwd: Updated PortAudio package forUbuntu(Needtesters!)

Hi Bill,

Ok, let's try to fix it untill we win. Is it possible if you could compile 
PA library with debugging output enabled (PA_ENABLE_DEBUG_OUTPUT shall be 
defined in makefile manually, or use confgure with 
option --enable-debug-output) I added there some useful logging information 
which also tells the type of device (mmaped, non-mmaped) and some details on 
host buffer calculations. This might help me to reproduce your config. I am 
so sad that ALSA is so picky...

Regards,
Dmitry.

----- Original Message ----- 
From: "Bill Good" <bkgood <at> gmail.com>
To: <portaudio <at> music.columbia.edu>
Sent: Monday, August 02, 2010 2:53 AM
Subject: [Portaudio] Fwd: Fwd: Updated PortAudio package 
forUbuntu(Needtesters!)

>> Dmitry Kostjuchenko dmitrykos at iauxsoft.com
>> Fri Jul 30 08:57:28 EDT 2010
>> In addition to my prev. message:
>>
>> I managed to test my last commit on real Ubuntu x64 and for me all works 
>> ok.
>> I tested sample rates: 44.1k, 48k, 96k and 192k, used different 
>> latencies,
>> managed to go down to 1.15ms. The device was not-mmaped and on Ubuntu x86
>> (in VirtualBox) mmaped. New changes seem to be working.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Bill Good | 2 Aug 2010 09:24
Picon

Re: Fwd: Fwd: Updated PortAudio package forUbuntu(Needtesters!)

Hi Dmitry,

I've got PortAudio HEAD compiled with debug output and pasted the output. 
Indeed, I don't know why ALSA isn't cooperating here. At least it's better 
than Linux 8 years ago, with everyone using OSS and the esound daemon :) Let 
me know if there's any other way I can be of help (do you need output for more 
than one user frames-per-buffer size? Attached is 512/~5ms).

Regards,
Bill

Debug: [Main]: SoundDevicePortAudio::open() "8, default" 
Debug: [Main]: m_dSampleRate 96000 
Debug: [Main]: iLatencyMSec: 5 
Debug: [Main]: output channels: 2 | input channels: 0 
Debug: [Main]: iFramesPerBuffer 512 
Debug: [Main]: iLatencyMSec: 5 
Debug: [Main]: Opening stream with id 8 
Debug: [Main]: m_pStream 0x0 
Debug: [Main]: pOutputParams: 
Debug: [Main]: device: 8 channelCount: 2 sampleFormat 1 suggestedLatency 0.005 
Debug: [Main]: sample rate: 96000 
Debug: [Main]: frames per buffer: 512 
Debug: [Main]: calback: true 
AlsaOpen: Opening device default
PaAlsaStreamComponent_InitialConfigure: device MMAP 
SND_PCM_ACCESS_MMAP_INTERLEAVED: YES
PaAlsaStreamComponent_InitialConfigure: device MMAP 
SND_PCM_ACCESS_MMAP_NONINTERLEAVED: YES
PaAlsaStreamComponent_InitialConfigure: device can MMAP: YES
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dmitry Kostjuchenko | 2 Aug 2010 10:07
Favicon

Re: Fwd: Fwd: Updated PortAudio package forUbuntu(Needtesters!)

Hi Bill,

Thanks for a quick log! It helps. These 3 lines are telling us about
this behavior:
PaAlsaStreamComponent_DetermineFramesPerBuffer: The determined period
size (512) is less than minimum (2047)
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period minimum = 2047
PaAlsaStreamComponent_DetermineFramesPerBuffer: device period maximum = 2049

It seems that in your case ALSA has fixed period size of 2048 and it
is really strange that our try to set min. (2047) fails. It looks like
a bug from ALSA side not ours but I will try to do something with
that.

Regards,
Dmitry.

2010/8/2 Bill Good <bkgood <at> gmail.com>:
> Hi Dmitry,
>
> I've got PortAudio HEAD compiled with debug output and pasted the output.
> Indeed, I don't know why ALSA isn't cooperating here. At least it's better
> than Linux 8 years ago, with everyone using OSS and the esound daemon :) Let
> me know if there's any other way I can be of help (do you need output for more
> than one user frames-per-buffer size? Attached is 512/~5ms).
>
> Regards,
> Bill
>
> Debug: [Main]: SoundDevicePortAudio::open() "8, default"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dmitry Kostjuchenko | 2 Aug 2010 13:58
Favicon

Re: Fwd: Fwd: Updated PortAudio package forUbuntu(Needtesters!)

Bill,

I've just commited a patch which shall fix the problem I guess in such
specific situation you showed. Let me know how it works for you now.

Regards,
Dmitry.

2010/8/2 Dmitry Kostjuchenko <dmitrykos <at> iauxsoft.com>:
> Hi Bill,
>
> Thanks for a quick log! It helps. These 3 lines are telling us about
> this behavior:
> PaAlsaStreamComponent_DetermineFramesPerBuffer: The determined period
> size (512) is less than minimum (2047)
> PaAlsaStreamComponent_DetermineFramesPerBuffer: device period minimum = 2047
> PaAlsaStreamComponent_DetermineFramesPerBuffer: device period maximum = 2049
>
> It seems that in your case ALSA has fixed period size of 2048 and it
> is really strange that our try to set min. (2047) fails. It looks like
> a bug from ALSA side not ours but I will try to do something with
> that.
>
> Regards,
> Dmitry.
>
> 2010/8/2 Bill Good <bkgood <at> gmail.com>:
>> Hi Dmitry,
>>
>> I've got PortAudio HEAD compiled with debug output and pasted the output.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Good | 2 Aug 2010 19:43
Picon

Re: Fwd: Fwd: Updated PortAudio package forUbuntu(Needtesters!)

Dmitry,
This is working great on my system. Thanks again!

Regards,
Bill

On Monday 02 August 2010 06:58:37 Dmitry Kostjuchenko wrote:
> Bill,
> 
> I've just commited a patch which shall fix the problem I guess in such
> specific situation you showed. Let me know how it works for you now.
> 
> Regards,
> Dmitry.
> 
> 2010/8/2 Dmitry Kostjuchenko <dmitrykos <at> iauxsoft.com>:
> > Hi Bill,
> > 
> > Thanks for a quick log! It helps. These 3 lines are telling us about
> > this behavior:
> > PaAlsaStreamComponent_DetermineFramesPerBuffer: The determined period
> > size (512) is less than minimum (2047)
> > PaAlsaStreamComponent_DetermineFramesPerBuffer: device period minimum =
> > 2047 PaAlsaStreamComponent_DetermineFramesPerBuffer: device period
> > maximum = 2049
> > 
> > It seems that in your case ALSA has fixed period size of 2048 and it
> > is really strange that our try to set min. (2047) fails. It looks like
> > a bug from ALSA side not ours but I will try to do something with
> > that.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dmitry Kostjuchenko | 2 Aug 2010 19:48
Favicon

Re: Fwd: Fwd: Updated PortAudio packageforUbuntu(Needtesters!)

Bill,

I am very glad! and thanks for the feedback. I hope we really overcame all 
the issues with ALSA. It seems that we met with some specific behavior 
because on my Ubuntu x64 I did not have such buffer period limitation and 
all what I tested (similar to your parameters) was working.

Best regards,
Dmitry.

----- Original Message ----- 
From: "Bill Good" <bkgood <at> gmail.com>
To: "Portaudio Mailing List" <portaudio <at> music.columbia.edu>
Sent: Monday, August 02, 2010 8:43 PM
Subject: Re: [Portaudio] Fwd: Fwd: Updated PortAudio 
packageforUbuntu(Needtesters!)

> Dmitry,
> This is working great on my system. Thanks again!
>
> Regards,
> Bill
>
> On Monday 02 August 2010 06:58:37 Dmitry Kostjuchenko wrote:
>> Bill,
>>
>> I've just commited a patch which shall fix the problem I guess in such
>> specific situation you showed. Let me know how it works for you now.
>>
>> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Irving | 3 Aug 2010 15:19
Picon

WASAPI compiling pa_win_wasapi.c fails

Trying to compile the latest svn r1533 fails.  Compiles and works fine 
using r1528.

I'm using gcc 3.4.4 mingw from the latest cygwin.

configure --with-host_os=mingw --with-winapi=wasapi --without-jack \
--enable-shared=no --enable-debug-output=no

Compile fails using --with-jack as well.

Configuration summary:

   Target ...................... i686-pc-cygwin
   C++ bindings ................ no
   Debug output ................ no

   WMME ........................ no
   DSound ...................... no
   ASIO ........................ no
   WASAPI ...................... yes
   WDMKS ....................... no

src/hostapi/wasapi/pa_win_wasapi.c: In function
  `ConvertJackConnectionTypeWASAPIToPA':
src/hostapi/wasapi/pa_win_wasapi.c:3553: error:
  `eConnType3Point5mm' undeclared (first use in this function)
src/hostapi/wasapi/pa_win_wasapi.c:3553: error:
  (Each undeclared identifier is reported only once
src/hostapi/wasapi/pa_win_wasapi.c:3553: error:
  for each function it appears in.)
(Continue reading)

Permalink | Reply | 22 comments |
headers
Reid Bishop | 3 Aug 2010 20:18

Re: WASAPI compiling pa_win_wasapi.c fails

Ralph,

Not fully knowing how compiles with mingw work; those defines that are being
complained about reside in KsMedia.h (which for VS compilers is part of the
Windows SDK.)  If not mistaken, the previous requirements of this type were
copying the required .h files from the Windows SDK into
src/hostapi/waspai/mingw-include (which I don't agree with.)  I am not sure
Dmitry did this.

-Reid-

-----Original Message-----
From: portaudio-bounces <at> music.columbia.edu
[mailto:portaudio-bounces <at> music.columbia.edu] On Behalf Of Ralph Irving
Sent: Tuesday, August 03, 2010 7:20 AM
To: portaudio <at> music.columbia.edu
Subject: [Portaudio] WASAPI compiling pa_win_wasapi.c fails

Trying to compile the latest svn r1533 fails.  Compiles and works fine 
using r1528.

I'm using gcc 3.4.4 mingw from the latest cygwin.

configure --with-host_os=mingw --with-winapi=wasapi --without-jack \
--enable-shared=no --enable-debug-output=no

Compile fails using --with-jack as well.

Configuration summary:
(Continue reading)

Permalink | Reply | 21 comments |

Gmane