On Fri, 2012-07-20 at 17:32 -0300, Flavio Ceolin wrote:
Tanu Kaskinen ta...@iki.fi writes:
There were problems with the code. I don't remember what exactly was
broken, though. But at least I didn't like the concurrency handling: I
really dislike doing inter-thread communication by using
On Fri, 2012-07-20 at 19:30 +0200, Robert M. Albrecht wrote:
Hi,
I'm using a M-Audio Fast Track Ultra on Fedora 17.
And you're having problems in alsa device detection, according to the
subject. A pulseaudio log of the pulseaudio startup would be useful:
https://wiki.ubuntu.com/PulseAudio/Log
On Thu, 2012-07-19 at 00:41 +0200, Christian K. wrote:
Hello,
I'm currently trying to connect PulseAudio with VLC using RTP. The SDP
sent by VLC is not parsed by PulseAudio, the error is invalid
header.
I discovered that PulseAudio seems to expect that the SDP descriptor
contains just LF
Hello,
Le jeudi 19 juillet 2012 01:41:52 Christian K., vous avez écrit :
I'm currently trying to connect PulseAudio with VLC using RTP. The SDP
sent by VLC is not parsed by PulseAudio, the error is invalid
header.
I discovered that PulseAudio seems to expect that the SDP descriptor
Having an object model that properly links ports to both cards and
sinks/sources would very likely be useful in the future also. Actually,
poljar has had the same problem with his latency offset feature. I don't
know if he already has a solution that you could re-use...
I added a port
Hello,
I'm running Ubuntu 12.04 with two computers both with AMD video
chipsets. Both of the sinks I need to output sound on have no mode
setting in Gnome sound config. The analog outputs show surround options
available, but S/PDIF and HDMI options only offer stereo output. Is
there
On Jul 20, 2012, at 1:53 PM, Pierre-Louis Bossart wrote:
Weird. Can you try setting both frequencies to 44100 and see what happens? I
can't think of any reason why this behavior happens.
If I set the default and alternate sample rates to 44100 in daemon.conf
it doesn't display any error
2012-7-19 上午6:14 於 Matthew Gregan kine...@flim.org 寫道：
No, it's just a random value for media playback. In an older version of
the
audio backend we're using in Firefox (which was push rather than pull
based), we used 500ms and hadn't run into this problem in a way that was
obvious to users
