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>
