Hallo Group,
Until now I use Xaudio for my application xgmc.
I want to get rid of it because
*It seems very out of date
*it when decoding it outputs much 0's at at the very first output.
I dont want this. I immediately want data.
*It seems that the granularity in positioning within within the
>> My own approach to this has tended to be to deliver data directly to
>> the device driver (i.e. do not use a "sequencer" layer) at my best
>> approximation to when it should be delivered to the wire, and assume
>> that the device driver and the hardware will work hard to do the best
>> they can
> I think this is much harder than you think :) Most MIDI devices cannot
> tell you when MIDI data will be delivered to the wire. Even the at the
> hardware level, there is a (small) FIFO that buffers between the
> device driver and the UART chip. On decent hardware, this tends to be
> 8-16 bytes
> >Another thing, does jack support pitch for hardware that has it?
>
> JACK doesn't directly interact with audio hardware at all. Only a JACK
> driver does that. At this time, the only existing driver is written to
> use the ALSA API to interact with audio interface hardware. It doesn't
> know a
Hello,
On Mon, 2002-02-25 at 07:54, David Fletcher wrote:
>
> > "SK" == Stefan Kost <[EMAIL PROTECTED]> writes:
>
> SK> The idea was brought up, because I say quite a few site a
> SK> sourceforge, which have a link " is part of the
> SK> foundry" at their top. I though it would probably
>
On Mon, 25 Feb 2002, Paul Davis wrote:
> I've never come across audio hardware that has this feature, and I'm
> not sure I'd want to. You can't, for example, use external word clock
> with such a device (not without some hairy firmware on the hardware),
> which means it would hard to use it in an
>OK. So say I have an application dealing with audio video and MIDI. Most
>of the time the audio will be used for the clock providing 'performance
>time'. Video and MIDI will have to be synced to this time.
in my experience (limited), its really hard to convince the video
people to buy this. the
One thing I forgot to answer:
>Another thing, does jack support pitch for hardware that has it?
JACK doesn't directly interact with audio hardware at all. Only a JACK
driver does that. At this time, the only existing driver is written to
use the ALSA API to interact with audio interface hardware
> "SK" == Stefan Kost <[EMAIL PROTECTED]> writes:
SK> The idea was brought up, because I say quite a few site a
SK> sourceforge, which have a link " is part of the
SK> foundry" at their top. I though it would probably
SK> useful for media-related projects too. The more I think about it,
SK>
> The envisioned used for UST in dmSDK/OpenML seems to be merely as a
> way to correct drift, but this could be a rather bad idea if the
> source of UST isn't synchronized with the hardware driving the
> reference output stream. For example, the natural source of UST on an
> Intel system would be
Hello Kai,
> On Thu, 21 Feb 2002, Stefan Kost wrote:
>
>
>>Just to quickly introduce myself, as I am new to the list (and to
>>linux/unix-audio too), I am working since 1983 on a audio-processing
>>package which is called SoundFX (see http://www.sonicpulse.de) and is
>>avaiable form the Amiga-p
>You are correct in saying that UST/MSC can't provide sample accurate
>audio sync, and I don't think it is ment for that. This has to be done at
>the hardware level.
it has to be done on 2 levels:
* participating hardware outputs need to be able to ensure that
their rate of data consu
> >The idea of a single 'system clock', (POSIX CLOCK_MONOTONIC would do)
> >to synchronise different media streams and midi (which is not in
> >OpenML) is the correct way IMHO.
>
> in existing digital systems, the way you synchronize independent
> streams is to provide a common *driving* clock sig
13 matches
Mail list logo
