Re: [pulseaudio-discuss] Weird data flow (not waveform)
I finally got it. Looks like, when I was parsing and/or dumping the stream to a file, the stream operator does not natively accept the types defined in stdint like int16_t. Once I placed a cast (int) it worked flawlessly :) 2010/6/15 David Henningsson launchpad@epost.diwic.se: On 2010-06-15 20:49, José Tomás Tocino García wrote: I think that's not the problem, because Gnuplot does not expect a exact format, it renders whatever it gets. The thing is, a usual waveform gets positive and negative values all the time. Sometimes that's what some DSP algorithms use to measure frequency, but given the stream has this weird representation, they do not work. That's what bugged me in first place, so I used gnuplot to visually check the waveform. Isn't is supposed to be a PCM waveform? Yes it is. If your mic has a DC offset you might get only negative or only positive levels though. What sample spec are you using in your call to pa_simple_new? Perhaps you have to specify the exact format for gnuplot, if it guesses wrong. By the way, there are plenty of programs that do simple recording - arecord, parecord, audacity etc should be able to do that as well. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- José Tomás Tocino García ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weird data flow (not waveform)
I think that's not the problem, because Gnuplot does not expect a exact format, it renders whatever it gets. The thing is, a usual waveform gets positive and negative values all the time. Sometimes that's what some DSP algorithms use to measure frequency, but given the stream has this weird representation, they do not work. That's what bugged me in first place, so I used gnuplot to visually check the waveform. Isn't is supposed to be a PCM waveform? 2010/6/15 David Henningsson launchpad@epost.diwic.se: On 2010-06-15 20:19, José Tomás Tocino García wrote: Hi, I'm using the Pulseaudio Simple Api to get the microphone input. It works ok, because I can hear exactly what I say on the mic if I open an output stream, but if I dump the audio stream to a file and then plot it (using gnuplot for instance), it's got nothing to do with a waveform. I realized so when I was trying to apply a FFT to the read stream, I was getting weird results. Have you checked that the sample format is matched? E g if the output from PA is 16 bit signed and gnuplot is expecting floating-point, or perhaps the other way around. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- José Tomás Tocino García ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weird data flow (not waveform)
On 2010-06-15 20:49, José Tomás Tocino García wrote: I think that's not the problem, because Gnuplot does not expect a exact format, it renders whatever it gets. The thing is, a usual waveform gets positive and negative values all the time. Sometimes that's what some DSP algorithms use to measure frequency, but given the stream has this weird representation, they do not work. That's what bugged me in first place, so I used gnuplot to visually check the waveform. Isn't is supposed to be a PCM waveform? Yes it is. If your mic has a DC offset you might get only negative or only positive levels though. What sample spec are you using in your call to pa_simple_new? Perhaps you have to specify the exact format for gnuplot, if it guesses wrong. By the way, there are plenty of programs that do simple recording - arecord, parecord, audacity etc should be able to do that as well. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
