From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Allan Klinbail <aklinbail@gmail.com>, alsa-devel@alsa-project.org
Subject: Re: A&H Zed R16 not completely working (DICE Jr)
Date: Thu, 21 Apr 2016 13:59:37 +0900 [thread overview]
Message-ID: <57185E39.5090401@sakamocchi.jp> (raw)
In-Reply-To: <CA+aoAJeU=y=mP0=_xeQXDfcG5uWg8azpuddQG6MxJ=NEZkA31A@mail.gmail.com>
Hi,
On Apr 21 2016 11:52, Allan Klinbail wrote:
> I have read the posted paper, and while I basically understand it's
> premise, I don't feel that this approach is necessarily suitable for
> "prefoessional" audio use cases (with DAW software and other music
> production software). I feel I understand why the Jack developers have
> maintained the traditional approach. Although I admit my understanding is
> basic and limited.
>
> Latency in this case is specifically important from a "Round trip"
> viewpoint, the time for the audio reaching the AD converter being processed
> by the DAW application (and associated plugins) to the time it reaches the
> DA converter.
> There are fixed latencies, such as introduced by the converters and also
> the latency from the speaker distance to the ears of the musician. (if
> monitoring headphones are not being used by the musician). For a musician
> to be able to process their mechnical movements at the correct time to the
> audio they are hearing requires a fixed latency to occur and typically this
> needs to be under 10ms for their not to be a perceived delay.
>
> This is starkly different from typical desktop usage or even gaming usage
> where multiple random audio streams are expected.
>
> Audio streams in DAW use cases, are highly predictable. In a typical setup,
> there will be no audio coming from sources outside of the DAW framework
> (this may involve and intercommunicating applications, however there would
> be no random media player startups, or sound coming from a new web page for
> example).
>
> The ability to "rewind" to insert new streams into the path of the hardware
> buffers is not typical for these circumstances.
You have complete misunderstanding. The usage of audio workstation is
not so special in an aspect of using sound devices.
It better for you to distinguish the size of PCM buffer, the
communication delay on the data bus, process scheduling timing, and so
on. I think you roughly lump them togather as a name of 'latency', and
it brings unreasonable conclusions.
Regards
Takashi Sakamoto
next prev parent reply other threads:[~2016-04-21 4:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 14:31 A&H Zed R16 not completely working (DICE Jr) Allan Klinbail
2016-04-20 15:21 ` Takashi Sakamoto
2016-04-20 16:03 ` Allan Klinbail
2016-04-20 16:09 ` Allan Klinbail
2016-04-21 0:01 ` Takashi Sakamoto
2016-04-21 0:14 ` Allan Klinbail
2016-04-21 2:11 ` Takashi Sakamoto
2016-04-21 2:52 ` Allan Klinbail
2016-04-21 4:59 ` Takashi Sakamoto [this message]
2016-04-21 5:38 ` Allan Klinbail
2016-04-21 9:49 ` Takashi Sakamoto
2016-04-21 21:16 ` Allan Klinbail
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57185E39.5090401@sakamocchi.jp \
--to=o-takashi@sakamocchi.jp \
--cc=aklinbail@gmail.com \
--cc=alsa-devel@alsa-project.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.