On Sun, December 2, 2012 1:00 pm, Ken Restivo wrote:
> Why am I asking these dumb-ass questions now? Because I've been playing
I don't know if realtime would fix this. This is not a low latency
operation unless you are using the same machine for studio monitoring (not
the way I would do it for sure) but rather a matter of having a large
enough buffer to play with and setting buffer refill soon enough and with
the priority it needs to refill in time.
Having a bigger priority than apache may not be enough, the buffer needs
to be big enough that the largest packet apache sends to the NIC driver
has time to get gone and load the audio in. In other words once apache has
sent a packet to the network stack, the packet(s) that the network stuff
has in the queue has to be gone before your audio can get sent.
So if you are using Jack, try setting the latency twice or more and see if
that helps. Then if that doesn't help it is time to get Liquidsoap to have
a bigger packet size and maybe to try and get more packets into the
network queue at a time. There may be some settings in apache that makes
it send smaller packets too.
So I would envision a studio box with whatever is needed to make the
studio work with s/pdif out to s/pdif in on the server. The studio runs
jack with ~5ms latency and the server runs with ~200ms latency or
something like that. Some software that can have ~5ms latency in and
~200ms latency out would work too, but I don't know if such a thing
exists, though it doesn't sound that hard to make. (though Len hasn't done
any of this kind of programing at all so use the grain of salt thing)
There are lots of people here with much more experience in audio
programing who may have a better solution.
Linux-audio-user mailing list