headers
Yong Hyeon Yoon | 1 Sep 2007 06:23

Re: PortAudio and Java Sound

Hi all,

I've released YavaSound Source codes with the same license as PortAudio.
YavaSound is a Java Sound SPI implementation with PortAudio.

It can be downloaded from:
http://YavaSound.inPrinciple.org/YavaSoundSource.zip

Regards,
Yong
Permalink | Reply | 2 comments |
headers
Mike Gorse | 1 Sep 2007 13:12

lock-up with ALSA

I am experiencing a lock-up when using PortAudio with ALSA.  There is a 
xrun, and PaAlsaStream_HandleXrun gets called.  It then calls AlsaRestart, 
which calls AlsaStop with abort == 0, and AlsaStop calls snd_pcm_drain, 
which jams and never returns.  This happens with espeak and seemingly only 
when it generates multiple consecutive utterances, although I can't guess 
as to why its generating multiple utterances in particular would lead to 
this behavior.  I run into this on my laptop, which is running Ubuntu 
Gutsy with alsa 1.0.14 and uses the snd-intel8x0 driver.  I do not have 
the trouble on my desktop, which has an on-board Via sound chip.

I can get around this by setting abort to 1 in AlsaStop if a xrun has 
occurred; this causes some choppiness rather than a lock-up.  I don't know 
if this is a patch that should go into portaudio, though, or if there is a 
better way to solve things.  (Are there circumstances when snd_pcm_drain 
would be expected to jam?)

Thanks for any advice, and let me know if there is anything else I can do 
to track this down.

-- Mike Gorse / AIM:linvortex / http://mgorse.freeshell.org --
Permalink | Reply | 4 comments |
headers
Yong Hyeon Yoon | 2 Sep 2007 10:32

Re: PortAudio and Java Sound

----- Original Message ----- 
> It can be downloaded from:
> http://YavaSound.inPrinciple.org/YavaSoundSource.zip

The download link has changed to:
http://KuroSound.inPrinciple.org/KuroSound.zip

Regards,
Yong
Permalink | Reply | 1 comment |
headers
Yong Hyeon Yoon | 2 Sep 2007 21:53

Re: PortAudio and Java Sound

Hi,

I've added a basic implementation of Clip interface to KuroSound.

Regards,
Yong
Permalink | Reply | 0 comments |
headers
Yong Hyeon Yoon | 3 Sep 2007 05:18

Re: PortAudio and Java Sound

hi,

I've added LineListener implementation in Line and DataLine.
I guess most of interfaces except Port in sampled.* are taken care of now.

I think Port implementation will involve some more PortAudio coding.
I will see how it turns out. :)

regards,
yong
Permalink | Reply | 1 comment |
headers
David Viens | 4 Sep 2007 16:14
Favicon

Requirements for compiling the official VC6 project files (dsw/dsp) of pa1.9

Hi

   Ive been asked to give some info on this, and in the mean time some justification.
VC6 is an old - VERY old - 1998 product.  The bugs it contains and the windows headers that
comes with it are a menace to software development.. But there are ways to get the best out of the
very important advantage it has:

It can link to those trusted, protected - and shipped in all version of windows -
msvcrt.dll and msvcp60.dll libraries, where as vc2001/2003/2005 all require
runtime redistributable.  (vc2001 doesn't count since its really imho a beta product)
(note this only applies if you like to link with "Multithreaded DLL" crt run time, the rationale
for using this exclusively is outside the scope of this email :) Lets just say msvcrt.dll is used
by like 95% of XP SP2's own dlls. - same heap, happy Virtual address space (VAS).

But VC6 is old and you can't get by compiling anything these days without "refreshing" it.
The following mirrors the setup plogue uses to build any x86-32 apps and dlls that we currently ship:

   -Install Vanilla VC6 from the original CDs.

   -Service pack 5:
      Latest known URL:
      http://msdn2.microsoft.com/en-us/vstudio/aa718363.aspx
      Yes there EXISTS a service pack 6 , but the processor pack (below) isnt compatible with it.
	
   -Processor Pack(only works with above SP5)
      Latest known URL:
      http://msdn2.microsoft.com/en-us/vstudio/aa718363.aspx
      This isnt absolutely required for portaudio, but if you plan on using SSE intrinsics and similar things.
      Up to you to decide upon Service pack 5 or 6 depending on your need for intrinsics.
      The Service pack 6 is NOT compatible with the processor pack, but
(Continue reading)

Permalink | Reply | 13 comments |
headers
Arve Knudsen | 4 Sep 2007 22:49
Picon
Favicon

Re: lock-up with ALSA

Hi Mike

On Sat, 01 Sep 2007 13:12:54 +0200, Mike Gorse <mgorse <at> mgorse.dhs.org>  
wrote:

> I am experiencing a lock-up when using PortAudio with ALSA.  There is a  
> xrun, and PaAlsaStream_HandleXrun gets called.  It then calls  
> AlsaRestart, which calls AlsaStop with abort == 0, and AlsaStop calls  
> snd_pcm_drain, which jams and never returns.  This happens with espeak  
> and seemingly only when it generates multiple consecutive utterances,  
> although I can't guess as to why its generating multiple utterances in  
> particular would lead to this behavior.  I run into this on my laptop,  
> which is running Ubuntu Gutsy with alsa 1.0.14 and uses the snd-intel8x0  
> driver.  I do not have the trouble on my desktop, which has an on-board  
> Via sound chip.
>
> I can get around this by setting abort to 1 in AlsaStop if a xrun has  
> occurred; this causes some choppiness rather than a lock-up.  I don't  
> know if this is a patch that should go into portaudio, though, or if  
> there is a better way to solve things.  (Are there circumstances when  
> snd_pcm_drain would be expected to jam?)
>
> Thanks for any advice, and let me know if there is anything else I can  
> do to track this down.

I've found in the past that snd_pcm_drain may lock up when used on the  
"dmix" device, so AlsaStop should call snd_pcm_drop instead if this device  
is detected. I'll ask on the ALSA-lib mailing list what the deal really is  
with snd_pcm_drain, and how it should be used to avoid lockups.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arve Knudsen | 4 Sep 2007 23:05
Picon
Favicon

Re: OSS and powers-of-two buffer sizes

Hi Albert

I'm willing to accept a patch for this issue :)

Arve

On Tue, 21 Aug 2007 14:34:35 +0200, Albert Santoni <asantoni <at> uwo.ca> wrote:

> Hi Ross,
>
>
>
> Hardly a concrete source, but the ALSA wiki states:
> "You must set period size and buffer size to power of two for the dmix
> plugin, because OSS API does not allow other values." [1]
>
> The OSS programmer's guide says:
> "Using an integer power of 2 (i.e. 4, 8, 16, 32, etc.) is recommended as
> this works best with the buffering used internally by the driver." [2]
>
> It's hard to come up with a concrete source here. Googling revealed some
> comments about powers-of-two fragment sizes inside drivers, but that
> could only be the case for certain drivers. I'm not totally convinced
> yet either.
>
> In the meantime, here's a snippet to round to the next power-of-two:
>
>         unsigned int iFramesPerBuffer = [latency in samples / number of
> buffers]
> 	unsigned int i;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arve Knudsen | 4 Sep 2007 23:10
Picon
Favicon

Re: 10 devices limit

I never got any answer to this, so I've simply chosen to raise the OSS  
device limit to 100. It should at least help people in Mikko's situation.

Arve

On Tue, 07 Aug 2007 22:54:13 +0200, Arve Knudsen <aknuds-1 <at> broadpark.no>  
wrote:

> Does anyone have any suggestion as to how to find all OSS devices?  
> Currently, PA only tries to use up to /dev/dsp9, ignoring a device if it  
> can't be found (i.e., no corresponding file). Would it perhaps be an  
> idea to raise the max number of devices (what should be the limit?), and  
> then iterate until the last device is found (e.g., /dev/dsp9 can't be  
> found -> /dev/dsp8 is the last device)?
>
> Arve
>
> On Fri, 27 Jul 2007 16:09:01 +0200, Mikko Tuumanen <mijutu <at> utu.fi> wrote:
>
>> Hello.
>>
>> Please, change the maximum number of oss devices way higher than
>> 10 in pa_unix_oss.c
>>
>> For example I have 2 lynxTWO soundcards in one computer at work and  
>> there:
>>
>> avuser <at> av:~$ ls /dev/dsp*|wc -l
>> 44
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gorse | 4 Sep 2007 23:33

Re: lock-up with ALSA

Hi Arve,

>> I can get around this by setting abort to 1 in AlsaStop if a xrun has 
>> occurred; this causes some choppiness rather than a lock-up.  I don't know 
>> if this is a patch that should go into portaudio, though, or if there is a 
>> better way to solve things.  (Are there circumstances when snd_pcm_drain 
>> would be expected to jam?)

> I've found in the past that snd_pcm_drain may lock up when used on the "dmix" 
> device, so AlsaStop should call snd_pcm_drop instead if this device is 
> detected. I'll ask on the ALSA-lib mailing list what the deal really is with 
> snd_pcm_drain, and how it should be used to avoid lockups.

Okay, thanks.  For what it's worth, the device is called "front" in my 
case, according to Portaudio anyway.
Permalink | Reply | 2 comments |

Gmane