headers
Kunal Ekawde | 1 Aug 2005 15:16
Picon

[QUERY]Audio Format to MULAW

Hello Group,

Im using v18 version of portaudio.
My Application uses portaudio (not PABLIO), but i need to get data in MULAW
format so that i can feed it to USB device connected to Telephone.Since as
of now i get PCM data, i want to convert it to MULAW format. I tried
changing the "wFormatTag" parameter(and other related) in
"PaHost_OpenOutputStream" function of pa_win_wmme.c file, but that didnt
help.On this "Pa_OpenStream" is called again with other
parameters(numInputChannels and numOutputChannels.

Any information will be usefull

Kunal Ekawde
Permalink | Reply | 0 comments |
headers
Roger B. Dannenberg | 10 Aug 2005 17:19
Picon
Favicon

RE: Portaudio digest, Vol 1 #1160 - 2 msgs

There is code for MULAW/PCM conversion in Nyquist, which is on SourceForge
as well as at CMU. -Roger
Permalink | Reply | 0 comments |
headers
Chris Share | 18 Aug 2005 01:34
Picon
Picon
Favicon

Timer Question

Hi,

I'd like to create a simple metronome that plays back an audio sample 
for each click.

I've managed to get Portaudio to play back a sample, however I'm unclear 
as to how I should implement the timing part of the program.

My initial thoughts are to keep track of the number of output samples 
that have been generated and use this number to determine whether there 
should be a click or silence. For example, if I want one click per 
second, I'll output a click and then 44100 samples later (the sample 
rate is 44100 samples per second) output the next click.

Is this the best way to do this?

Any advice would be much appreciated.

Cheers,

Chris
Permalink | Reply | 3 comments |
headers
Steve | 18 Aug 2005 05:05
Picon

Re: Timer Question

That's basically the idea.  If you want to output a sound at a
specific time interval, using the sample counter is probably the most
accurate way to go.  You can use a counter modulo 44100 and have it
begin outputting the sound data when counter=0.

Alternatively you could have a seperate timer that sets a flag telling
the audio callback when to start playing a sound (ie., "now.. now...
now...") but that will be a bit more complicated.  However it may be
useful if you plan on interating with MIDI events.  Your latency will
be related to your buffer size.

Steve

On 8/17/05, Chris Share <cshare01 <at> qub.ac.uk> wrote:
> Hi,
> 
> I'd like to create a simple metronome that plays back an audio sample
> for each click.
> 
> I've managed to get Portaudio to play back a sample, however I'm unclear
> as to how I should implement the timing part of the program.
> 
> My initial thoughts are to keep track of the number of output samples
> that have been generated and use this number to determine whether there
> should be a click or silence. For example, if I want one click per
> second, I'll output a click and then 44100 samples later (the sample
> rate is 44100 samples per second) output the next click.
> 
> Is this the best way to do this?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Share | 18 Aug 2005 10:56
Picon
Picon
Favicon

Re: Timer Question

Hi,

Thanks for your reply.

Another quick question: If I use the second method you've suggested, 
what timer should I use? Am I right in thinking there is one for MME, 
and another for DirectX? What about ASIO? Do I have to use the same 
timer as Portaudio?

Also, I'm not sure about the status of the project--it might be open 
source or it might be shareware.

Cheers,

Chris

Steve wrote:
> That's basically the idea.  If you want to output a sound at a
> specific time interval, using the sample counter is probably the most
> accurate way to go.  You can use a counter modulo 44100 and have it
> begin outputting the sound data when counter=0.
> 
> Alternatively you could have a seperate timer that sets a flag telling
> the audio callback when to start playing a sound (ie., "now.. now...
> now...") but that will be a bit more complicated.  However it may be
> useful if you plan on interating with MIDI events.  Your latency will
> be related to your buffer size.
> 
> 
> Steve
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric | 18 Aug 2005 16:12
Favicon

RE: Timer Question

Chris,

I would think that you could just use the callbacks to count the samples
that have passed.  This would be a implementation independent solution
that should work for all 3 windows hosts (MME, DS, ASIO).

Eric Wachsmann
FlexRadio Systems

-----Original Message-----
From: portaudio-admin <at> techweb.rfa.org
[mailto:portaudio-admin <at> techweb.rfa.org] On Behalf Of Chris Share
Sent: Thursday, August 18, 2005 3:57 AM
To: Portaudio Mailing List
Subject: Re: [Portaudio] Timer Question

Hi,

Thanks for your reply.

Another quick question: If I use the second method you've suggested, 
what timer should I use? Am I right in thinking there is one for MME, 
and another for DirectX? What about ASIO? Do I have to use the same 
timer as Portaudio?

Also, I'm not sure about the status of the project--it might be open 
source or it might be shareware.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Hildebrand | 22 Aug 2005 14:15
Picon
Favicon

I need some help with some basic stuff

I'm also new here, my name's Scott and I've done a bit
of 3D audio programming for UC Davis. My question is
about how to write a program that opens up a wave
file, manipulates the samples and then spits them
right out when I'm done with them. I wrote a lot of
code in Pd which is a real-time DSP environment, but
the syntax is quite different as you might guess.
Here's some of the code I have that works in a Pd
program:

//this part fills up the arrays with new audio data.

   while(n--) {
   new_left[couter] = *(in1++);
   new_right[counter] = *(in2++);
   couter++; 
   }

//I would then manipulate the samples and then output

//sends out the 512 samples
   for(readpos=0; readpos<NUMSAMPLES; readpos++)      
   {
   *(out1++) = new_left[readpos];
   *(out2++) = new_right[readpos];
   }

I would guess that the code and approach would be
simple but I haven't been able to figure it out yet.
Thanks for the help!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric | 22 Aug 2005 15:56
Favicon

RE: I need some help with some basic stuff

Scott,

If the function calls are short, you could probably just call them
directly in the callback (no hardware calls here though!).  If you are
working with audio files, you will probably need to queue them up in
some local buffers in order to prevent having to hit the disk while
inside the callback.

We use a ring buffer synchronization technique in our application with
PortAudio v19 to record/playback wave files.

Eric Wachsmann
FlexRadio Systems

-----Original Message-----
From: portaudio-admin <at> techweb.rfa.org
[mailto:portaudio-admin <at> techweb.rfa.org] On Behalf Of Scott Hildebrand
Sent: Monday, August 22, 2005 7:15 AM
To: portaudio <at> techweb.rfa.org
Subject: [Portaudio] I need some help with some basic stuff

I'm also new here, my name's Scott and I've done a bit
of 3D audio programming for UC Davis. My question is
about how to write a program that opens up a wave
file, manipulates the samples and then spits them
right out when I'm done with them. I wrote a lot of
code in Pd which is a real-time DSP environment, but
the syntax is quite different as you might guess.
Here's some of the code I have that works in a Pd
program:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Bailey | 17 Aug 2005 18:55
Picon

Port Audio and the new API 2.0

Hi,

I'm about to sit and rework some coursenotes for an "Audio Programming" course 
I run at The University of Glasgow. Until recently, we used dual-boot G3 
MacOS/Debian GNU/Linux machines, but now (and much against my better 
judgement) they've all been upgraded to MacOS-X G5 iMacs. Thinking this was a 
positive step, I thought I'd port the coursenotes to OS-X too, using 
portaudio as a mediator. All by examples will most likely be written on my 
Linux box at home, so this seems to be a recipe for success.

I noticed that the configure system is quite broken for the Mac platform in 
v18. This isn't  a big deal, and you can build and install the libraries if 
you are even slightly conversant with The Unix Way and read the docs. When I 
sat down to fix the scripts, I thought I'd try and switch to v19, but it 
turns out someone's fixed them already! Great!

Now the problem. I'll be using blocking I/O pretty much exclusively, as the 
course is really DSP-oriented rather than music-oriented, and the cohort 
aren't computer scientists and need a really, really simple API. v19 looks 
good for that, but it turns out from the status grid that blocking API isn't 
supported on mac_core. In fact, nothing is! Proposal 5 (blocking I/O with 
NULL callback) is listed as unimplementable on Jack (which was my preferred 
method of talking to OS-X at low-level anyway) but I don't understand why. 
Has pablio sort of disappeared from the library? I have it implementing 
blocking I/O above jack fine on the OS-X version of v18.

I'm now faced with a bit of dilemma. What do the developers recommend? Three 
options spring to mind:

	1. Go with 0.0.18, hand build it for OS-X, and put up with having to
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Oswald | 12 Aug 2005 16:10

Sound problem under Suse Linux 9.3 (ALSA 1.0.9), RME Hammerfall DSP Multiface

Hi all,
I'm experiencing rather strange sound problems with the latest
Portaudio Developer Version 1.9 under Suse Linux 9.3, using ALSA 1.0.9
on an RME Hammerfall DSP Multiface (driver is hdsp, tool used:
hdsploader/hdspmixer).
When using e.g. arecord -f cd test.wav and aplay test.wav, everythings
works fine, the data are recorded and played back without any problem.
Now I've made a very basic test using PA similar to patest_wire. It
just passes through one mic input to output. However, it seems that
some parts (end or start) of the incoming buffers are somehow
corrupted, since you hear drops/pops expecially with sound of higher
frequency (e.g. when you whistle). These problems are somehow
proportional to the buffer size (when you have very large buffers, the
frequency in which drops/pops occur is lower than with very short
buffers)...
Compiling and Running the same app under WinXP using the same PA
snapshot and the same Hammerfall (ASIO driver), I do not experience
these problems. Again back under Linux, the sample patest_wire suffers
from the same problem, so I assume it's not a problem of my code or
ALSA (since arecord/aplay work fine), but something related to
portaudio. Does anyone of you have an idea what's going wrong here??

FYI: The app uses paFloat32 sample format, 32000 khz sample rate;
buffer size is 1024, non-interleaved. The callback function looks like
this:

int audioCallback(const void *inputBuffer, void *outputBuffer,
unsigned long framesPerBuffer, const PaStreamCallbackTimeInfo*
outTime, PaStreamCallbackFlags flags, void* data)
{
(Continue reading)

Permalink | Reply | 0 comments |

Gmane