[pulseaudio-discuss] Problem using the Simple API

[eric]

For the archives, this was solved on IRC.  My problem was using the default
latency settings when calling pa_simple_new().  Setting
pa_buffer_attr.fragsize to an appropriate value gave me the data quicker.
 If I understood them correctly, the pulse volume control applet sets the
latency on all streams when it opens, which is why I was seeing that odd
behavior.  Thanks Lennart and phish3!

-eric

On Fri, Oct 30, 2009 at 6:36 PM, eric <ekilfoil at gmail.com> wrote:

>
>
> On Fri, Oct 30, 2009 at 6:23 PM, Lennart Poettering <
> lennart at poettering.net> wrote:
>
>> Returning immediately *instead* of giving you 640 bytes of PCM?
>>
>> I mean, are you suggesting that pa_simple_read() is in fact *not*
>> returning 640 bytes?
>>
>
> Or is your confusion simply because you expect that at 44khz you
>> expect that calling pa_simple_read() for 640 bytes will block for
>> exactly 3.6 ms? That's not how things work. If it did you'd get
>> dropouts in the time between two _read() calls.
>>
>
> I definitely expected 640 bytes of PCM (~0.01s i thought) to be returned.
>  I assumed that pa_simple_read() would block until I had that.  This was the
> behavior in 0.9.14.  Of course, it would be buffered, so I would expect from
> the time I opened the stream i would not have any data.  In other words:
>
> 1. Open stream
> 2. sleep for x seconds
> 3. 1000000 bytes of data are in a buffer
> 4. i read 640 bytes and get 640 bytes (this takes microseconds)
> 5. Eventually my read catches up with the buffer
>
> The above situation is not what I am dealing with.  This is not my
> situation at all. I would be fine if I eventually caught up with the buffer,
> but I never do, and as you pointed out, it's most likely because of latency.
>  I need to get data *at least* every .1s.
>
>
>>
>> if you want to do time synchronization, then query for the *time*,
>> don't count samples. The time will be independant of buffering and so
>> on. In the simple API there is pa_simple_get_latency() which you can
>> query before you read something and which will then tell you how much
>> earlier what you will read next was actually recorded.
>>
>
> I don't really need time sync.  If I drop packets, it's not *that*
> critical.  But under normal operation i need to get audio every .1s.
>
>
>> If you use the complex API then you can use pa_stream_get_time() to
>> get a stream time, relative to the beginning of the stream.
>>
>>
> I'm trying to avoid the complex API because.... frankly.. it's really
> complex.  Is there a way to set the latency using the simple API?
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20091031/bac08484/attachment.htm>