On 2014/01/08 14:10, Steven OBrien wrote:
> The high CPU load in the Alsa input plugin was caused
> by a mistake in the alsa software parameters configuration.
> Clearly I misunderstood what this particular setting was for.
> The attached patch simply removes the setting of that
> parameter and no
I'm having a real struggle with this yahoo email client.
What my previous message said was:
The high CPU load in the Alsa input plugin was caused
by a mistake in the alsa software parameters configuration.
Clearly I misunderstood what this particular setting was for.
The attached patch simply remo
On Tuesday, 7 January 2014, 22:56, j rocket wrote:
Steven, I dont know if this is any help to you but heres a link to a website
with c++ code that explains audio passthru..
One of the statements in the code example says this
If SND_PCM_NONBLOCK is used, read / write access to the */
/*
Steven, I dont know if this is any help to you but heres a link to a website
with c++ code that explains audio passthru..
One of the statements in the code example says this
If SND_PCM_NONBLOCK is used, read / write access to the */
/* PCM device will return immediately. If SND_PCM_ASYNC
On 2014/01/07 13:59, Steven OBrien wrote:
> Since my last update, I've been thinking that the alsa poll is
> really just a timer, it fires every time a fixed number of frames
> have been written to its internal buffer, and as a real-time stream
> this equates to a fixed number of milli-seconds. So
Max - the AlsaInputPlugin now consumes 120% CPU on my 2-core processor, roughly
60% on each processor. I think the alsa poll event is firing too often.
Since my last update, I've been thinking that the alsa poll is really just a
timer, it fires every time a fixed number of frames have been writt