Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1544037

Re: [TSN RFC v2 0/9] TSN driver for the kernel

From Richard Cochran <richardcochran@gmail.com>
Newsgroups linux.kernel
Subject Re: [TSN RFC v2 0/9] TSN driver for the kernel
Date 2016-12-17 21:10 +0100
Message-ID <sPtsS-5NV-9@gated-at.bofh.it> (permalink)
References <sP57b-75S-5@gated-at.bofh.it> <sP8Rs-Yj-19@gated-at.bofh.it> <sPjaa-7FU-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sat, Dec 17, 2016 at 10:05:54AM +0100, Henrik Austad wrote:
> I'm sending out a new set now because, what I have works _fairly_ well for 
> testing and a way to see what you can do with AVB. Using spotify to play 
> music on random machines is quite entertaining.

You have missed the point about TSN entirely.  Unless your demo has
synchronized playback (in the low microsecond range), then it really
is pointless.  We can already play music over the LAN using gstreamer,
without a single kernel change.  Heck, gstreamer even has its own
rudimentary synchronization, so your series is a step backwards.

> And therein lies the problem. It cannot yet be written, so we have to start 
> in *some* end. And as I repeatedly stated in June, I'm at an RFC here, 
> trying to spark some interest and lure other developers in :)

The best way to attract interest is to provide the critical
infrastructure missing in the kernel.  Coding a media player in kernel
space is not very interesting in my view.

> Yes, and this requires a lot of change to ALSA (and probably something in 
> V4L2 as well?), so before we get to that, perhaps have a set of patches 
> that does this best effort and *then* work on getting time-triggered 
> playback into the kernel?

No, we don't need a best effort implementation.  That is gstreamer and Co.

> So, the next issue I plan to tackle, is how I do buffers, the current 
> approach where tsn_core allocates memory is on its way out and I'll let the 
> shim (which means alsa/v4l2) will provide a buffer. Then I'll start looking 
> at qdisc.

More than once you wrote something like, "I know that's needed, but it
is just too hard ATM."  Please start with qdisc and tc.  That
shouldn't be too hard.  If we had the AVB shaping rules with one or
two drivers supporting them, that would be one piece already done.

Thanks,
Richard

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[TSN RFC v2 0/9] TSN driver for the kernel henrik@austad.us - 2016-12-16 19:10 +0100
  [TSN RFC v2 4/9] Adding TSN-driver to Intel I210 controller henrik@austad.us - 2016-12-16 19:10 +0100
  [TSN RFC v2 1/9] igb: add missing fields to TXDCTL-register henrik@austad.us - 2016-12-16 19:10 +0100
  [TSN RFC v2 8/9] AVB ALSA - Add ALSA shim for TSN henrik@austad.us - 2016-12-16 19:10 +0100
  [TSN RFC v2 5/9] Add TSN header for the driver henrik@austad.us - 2016-12-16 19:10 +0100
    Re: [TSN RFC v2 5/9] Add TSN header for the driver Richard Cochran <richardcochran@gmail.com> - 2016-12-16 23:20 +0100
      Re: [TSN RFC v2 5/9] Add TSN header for the driver Henrik Austad <henrik@austad.us> - 2016-12-17 10:00 +0100
  Re: [TSN RFC v2 0/9] TSN driver for the kernel Greg <gvrose8192@gmail.com> - 2016-12-16 19:20 +0100
    Re: [TSN RFC v2 0/9] TSN driver for the kernel David Miller <davem@davemloft.net> - 2016-12-16 19:30 +0100
      Re: [TSN RFC v2 0/9] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-12-16 20:10 +0100
  Re: [TSN RFC v2 0/9] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-12-16 23:10 +0100
    Re: [TSN RFC v2 0/9] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-12-17 10:10 +0100
      Re: [TSN RFC v2 0/9] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-12-17 21:10 +0100

csiph-web