2011/11/6 Paul Davis p...@linuxaudiosystems.com:
On Sun, Nov 6, 2011 at 2:20 AM, Emanuel Rumpf xb...@web.de wrote:
2011/11/5 Iain Duncan iainduncanli...@gmail.com:
On Thu, Nov 3, 2011 at 8:05 PM, David Robillard d...@drobilla.net wrote:
The only difference non-jack would make is you need
On Mon, Nov 7, 2011 at 6:45 PM, Emanuel Rumpf xb...@web.de wrote:
For example:
At f = 48000 Hz, I would expect a soundcard to deliver exactly 48000 *
10 = 48E4 samples in 10 seconds.
Is this assumtion wrong ?
no, but its a bit like relativity: who defines 10 seconds? the only
definition of
2011/11/5 Iain Duncan iainduncanli...@gmail.com:
On Thu, Nov 3, 2011 at 8:05 PM, David Robillard d...@drobilla.net wrote:
The only difference non-jack would make is you need some function to
tell you roughly what audio time it is you can call from another thread.
Does one use the system
On Sun, Nov 6, 2011 at 2:20 AM, Emanuel Rumpf xb...@web.de wrote:
2011/11/5 Iain Duncan iainduncanli...@gmail.com:
On Thu, Nov 3, 2011 at 8:05 PM, David Robillard d...@drobilla.net wrote:
The only difference non-jack would make is you need some function to
tell you roughly what audio time it
The only difference non-jack would make is you need some function to
tell you roughly what audio time it is you can call from another thread.
Does one use the system clock for that?
I think frame time (a frame of samples) is meant here ? That time is
delivered in the jackd process callback.
On 11/06/2011 07:10 AM, Paul Davis wrote:
fons wrote the canonical paper on this for a Linux Audio conference a
few years ago, and JACK contains a DLL for this purpose
(jack_get_microseconds() will return a prediction of the current time
according to the audio clock, based on the system clock
On Thu, Nov 3, 2011 at 8:05 PM, David Robillard d...@drobilla.net wrote:
On Thu, 2011-11-03 at 18:32 -0700, Iain Duncan wrote:
thanks Dave, that's what I was looking for! Have you used this
technique yourself? Do you have any suggestions on how that is done
with non jack systems? And any
Further to the conversation about Python to C++ ( with many helpful
responses, thanks everyone! ).
For my particular case, no drop outs is critical, and I really really want
to be able to run multiple UIs on lots of cheap machines talking to the
same engine over something (osc I expect). So I'm
On Thu, 2011-11-03 at 16:29 -0700, Iain Duncan wrote:
Further to the conversation about Python to C++ ( with many helpful
responses, thanks everyone! ).
For my particular case, no drop outs is critical, and I really really
want to be able to run multiple UIs on lots of cheap machines
thanks Dave, that's what I was looking for! Have you used this technique
yourself? Do you have any suggestions on how that is done with non jack
systems? And any open source code that uses that technique?
thanks so much.
iain
On Thu, Nov 3, 2011 at 5:42 PM, David Robillard d...@drobilla.net
On Thu, Nov 3, 2011 at 7:29 PM, Iain Duncan iainduncanli...@gmail.com wrote:
Further to the conversation about Python to C++ ( with many helpful
responses, thanks everyone! ).
For my particular case, no drop outs is critical, and I really really want
to be able to run multiple UIs on lots of
For my particular case, no drop outs is critical, and I really really want
to be able to run multiple UIs on lots of cheap machines talking to the
same
engine over something (osc I expect). So I'm ok with the fact that user
input and requests for user interface updates may lag, as the queue is
On Thu, Nov 3, 2011 at 9:44 PM, Iain Duncan iainduncanli...@gmail.com wrote:
For my particular case, no drop outs is critical, and I really really want
to be able to run multiple UIs on lots of cheap machines talking to the
same
engine over something (osc I expect). So I'm ok with the fact
On Thu, 2011-11-03 at 18:32 -0700, Iain Duncan wrote:
thanks Dave, that's what I was looking for! Have you used this
technique yourself? Do you have any suggestions on how that is done
with non jack systems? And any open source code that uses that
technique?
Yes, I use it in Ingen, where all
14 matches
Mail list logo