It pains me to have to bring this up again, but I've had to come back to the dmix/dsnoop way of doing things, and this issue remains. However, I don't think it's got anything to do with timestamp drift as I thought previously, but some oddity with ALSA.<div><br></div><div>If I set GST_DEBUG to 5 on alsa* plugins, I get this message repeatedly:</div><div>alsa gstalsasink.c:1023:gst_alsasink_write:<alsasink0> Write error: Resource temporarily unavailable</div><div><br></div><div>I've attached a complete copy of the log.<br><br>
On Fri, 8 Mar, 2013 at 10:42 AM, Nox Deleo <noxdeleo@googlemail.com> wrote:<br>
<blockquote type="cite"><p>Thanks for the suggestion, but I'm fairly sure I did that when messing around with the src/sink options, and it didn't seem to make any difference. Anyway, I managed to stop this issue in it's tracks today when I got rid of the dmix/dsnoop plugins (realised I didn't actually need to share my channels, just split them up) and used the route plugin instead. No problems whatsoever. So, maybe I screwed something up between the asoundrc for dmix/dshare and my GStreamer pipeline, or there's some weird issue between the two anyway.</p>
<div class="gmail_quote">On Mar 8, 2013 3:27 AM, "Nicolas Dufresne" <<a href="mailto:nicolas.dufresne@collabora.co.uk">nicolas.dufresne@collabora.co.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div>
Le lundi 04 mars 2013 à 18:37 +0000, Nox Deleo a écrit :<br>
<blockquote type="CITE">
I've tried adjusting buffer/sample sizes in my .asoundrc, messing with various options in alsasrc/sink, and even using a lowlatency kernel. These don't seem to do anything to diminish this problem. I could introduce latency problems by setting buffer/sample sizes too low, but this problem never changed at all, which makes me think it's not a straight latency issue.<br>
</blockquote>
Not that I have any solution here, but I'd like to mention that in this case it's not a latency issue but the audio clock speed not going the same speed as the selected clock. The distance can changed, in contrast with latency where the distance remain the same.<br>
<br>
One question, any reason not to use the audio clock and slave the other clocks to the audio clock ?<br>
<br>
Nicolas
</div>
<br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div>
</blockquote><br></div>