All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Henrik Austad <henrik@austad.us>, alsa-devel@alsa-project.org
Cc: Takashi Iwai <tiwai@suse.de>, hansverk@cisco.com, haustad@cisco.com
Subject: Re: [RFC] AVB - network-based soundcards in ALSA
Date: Mon, 26 May 2014 22:21:10 +0600	[thread overview]
Message-ID: <538369F6.4040306@gmail.com> (raw)
In-Reply-To: <20140526130352.GA17414@austad.us>

26.05.2014 19:03, Henrik Austad wrote:
> Hi all!
>
> This is an RFC for a new class of soundcards. I am not very familiar
> with how ALSA is tied together underneath the hood, so what you see
> here, is based on my naive understanding of ALSA. I wear asbestos
> underwear on a regular basis, so I prefer honesty over sugarcoating :)

Hello. All of this looks very interesting, but a bit more information is 
needed in order to put this in context.

First: is this supposed to work with any ethernet card? Or is some 
special hardware needed on the PC side? If so, which hardware?

Second: I would like to know more about the buffering model. For 
simplicity, let's consider playback from a PC to a remote receiver. 
Obviously, as the intention is to create something that looks like a 
regular ALSA sound card, there should be a circular buffer that holds 
sound samples (just like the DMA buffer on regular sound cards). There 
also needs to be "something" that sends samples from this buffer into 
the network. Is my understanding correct?

> * IEEE 1722 (and 1733 for layer-3) Layer 2 Transport for
>    audio/video. The packing is similar to what is done in Firewire. You
>    have 8kHz frame intervals for class A, 4kHz for class B. This gives
>    relatively few samples pr. frame. Currently we only look at Layer 2 as
>    small peripherals (microphones, speakers) will only have to implement
>    L2 instead of the entire IP-stack.

So, are you proposing to create a real-time kernel thread that will wake 
up 4000 or 8000 times per second in order to turn a few samples from the 
circular buffer into an Ethernet packet and send it, also advancing the 
"hardware pointer" in the process? Or do you have an idea how to avoid 
that rate of wakeups?

-- 
Alexander E. Patrakov

  reply	other threads:[~2014-05-26 16:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-26 13:03 [RFC] AVB - network-based soundcards in ALSA Henrik Austad
2014-05-26 16:21 ` Alexander E. Patrakov [this message]
2014-05-27  9:02   ` Henrik Austad
2014-05-27 12:10     ` Alexander E. Patrakov
2014-05-28  9:07       ` Henrik Austad
2014-05-27 13:47     ` Clemens Ladisch
2014-05-28  9:32       ` Henrik Austad
2014-05-28 13:12         ` Clemens Ladisch
2014-05-27 14:36 ` Takashi Iwai
2014-05-27 16:55   ` Pierre-Louis Bossart
2014-05-28  9:43     ` Henrik Austad
2014-05-28 15:14       ` Pierre-Louis Bossart

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=538369F6.4040306@gmail.com \
    --to=patrakov@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=hansverk@cisco.com \
    --cc=haustad@cisco.com \
    --cc=henrik@austad.us \
    --cc=tiwai@suse.de \
    /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.