[Jack-Devel] Jack and thunderbolt
Locked
1234
... 9
1234
... 9
 
|
I really battle to find the optimum solution for ultra low latency
monitoring using Linux. Since I am using Jack I have a few compatibility questions. 1) Is jack known to be able to work with thunderbolt 3 on Linux ? 2) Thunderbolt included, what is the lowest latency sound transport format that jack can work within your opinion on Linux e.g. thunderbolt / AES50 / Ultranet / Madi / etc _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
I haven’t measured lowest-possible latency, but I successfully use thunderbolt 3 from my HP laptop running Linux, via an Apple thunderbolt to FireWire adapter, to a Mackie Onyx FireWire mixer. The mixer appears as a normal FireWire interface to Jack.
bg > On Dec 5, 2018, at 17:47, [hidden email] wrote: > > I really battle to find the optimum solution for ultra low latency monitoring using Linux. > Since I am using Jack I have a few compatibility questions. > > 1) Is jack known to be able to work with thunderbolt 3 on Linux ? > 2) Thunderbolt included, what is the lowest latency sound transport format that jack can work within your opinion on Linux > e.g. thunderbolt / AES50 / Ultranet / Madi / etc > _______________________________________________ > Jack-Devel mailing list > [hidden email] > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by liebrecht
On Wed, December 5, 2018 4:47 pm, [hidden email] wrote:
> I really battle to find the optimum solution for ultra low latency > monitoring using Linux. For monitoring while recording, hardware monitoring is often optimum > Since I am using Jack I have a few compatibility questions. > 1) Is jack known to be able to work with thunderbolt 3 on Linux ? The jackd server uses ALSA for interfacing to most audio devices, although it does have a way to directly use some Firewire devices. Really the question should be is there a driver for a particular Thunderbolt device you want to use. My understanding is that Thunderbolt is basically PCIe with some slight modifications to allow hot plugging cables, determining whether the peripheral needs PCIe or DisplayPort protocol, a few other things, but the important point being it does not define audio transport as for example USB audio class does, so even if one Thunderbolt interface is supported by ALSA, that does not mean that other Thunderbolt interfaces would be supported, you would still need a driver that takes care of register level access to the specific device you want to use. > 2) Thunderbolt included, what is the lowest latency sound transport > format that jack can work within your opinion on Linux > e.g. thunderbolt / AES50 / Ultranet / Madi / etc That question is not well formed. Thunderbolt is a data transport used in computers, not specifically an audio transport. AES50 and MADI are specifically an audio transports, and no computer has a direct AES50 or MADI connection. So again, the question is what particular audio device would you like to use, and then see if there is an ALSA driver available. The lowest latency would be PCIe connection from your processor to a device with analog converters on board. Many people have reported good results from RME devices over the years. If you happen to already have an analog converter you like with AES3 or MADI interface, RME has cards with those transports as well. But that is specifically just addressing the lowest latency way to get data from your processor to an analog audio connection. You did not explain what you are trying to achieve, so spending money on an interface that can run with low latency may not be the best way to achieve what you really want. Not to mention that there are many more system considerations than just interface transport in determining latency, you can spend quite a bit of time optimizing your system for low latency, but there are still quite a few things out of your control on a modern Intel based system (such as system management mode firmware that runs outside of the control of the kernel scheduler). So do you need low latency for monitoring while recording? Probably hardware monitoring is optimal (either with an interface that supports hardware monitoring, or by using an external analog mixer, preamp, etc. which supports monitoring features). For software synthesizers? Then system latency will probably dominate over audio interface, you will have plenty to work on before nearly any interface is the limiting factor. -- Chris Caudle _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Thu, 6 Dec 2018 20:56:25 -0600, Chris Caudle wrote:
>The lowest latency would be PCIe connection from your processor to a >device with analog converters on board. Many people have reported good >results from RME devices over the years. FWIW I get lower latency using an USB Focusrite Scarlett 18i20 2nd gen, than using a PCIe RME HDSPe AIO, let alone that Linux can not access all IOs of the RME HDSPe AIO and that it can not be used with ALSA directly when using Ardour, this RME card can only be used with jack when using Ardour. It was this way with my old AMD machine and hasn't changed for my new Intel machine. Regarding MIDI jitter my best experiences are with PCI (Envy24, Terratec EWX 24/96) and PCIe (RME HDSPe AIO), but regarding audio latency USB (Presonus 1818VSL and even lower when using a Focusrite Scarlett 18i20 2nd gen) works best for me. YMMV! However, hardware monitoring when using Class Compliant USB devices usually can't be done by the audio device's internal routing, a mixing console is needed for latency free monitoring, while cards that need an individual ALSA driver, such as the HDSPe AIO might be able to use the internal hardware routing (e.g. by hdspmixer). -- pacman -Q linux{,-rt{-cornflower,,-securityink,-pussytoes}}|cut -d\ -f2 4.19.7.arch1-1 4.19.5_rt4-0 4.19.1_rt3-0 4.19_rt1-0 4.18.16_rt9-1 _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Fri, 07 Dec 2018, [hidden email] wrote:
>On 2018-12-07 00:54, Ralf Mardorf wrote: >> However, hardware monitoring when using Class Compliant USB devices >> usually can't be done by the audio device's internal routing, a >> mixing console is needed for latency free monitoring, while cards >> that need an individual ALSA driver, such as the HDSPe AIO might be >> able to use the internal hardware routing (e.g. by hdspmixer). >Thanks all for the insightful responses. > >The last part of your answer is something I dont see often. >Do you have any point of departure where I can read up about which >devices can access the onboard DSP of audio interfaces such as those >you mention eg 1818vsl or other. It is the first time I see hints of >someone or programs able to access the onboard DSP for low latency >monitoring. Didnt see this ever mentioned but it is desperately >needed. After receiving your post I tried to find similar on the web, >but it is all very unclear what is possible and for which devices. Please reply to the mailing list and don't top-post. That is probably a misunderstanding. The Presonus and the Focusrite 2nd gen USB devices don't provide access to the device's internal routing when using it with a Linux machine. They are class compliant and don't need individual drivers. Sound devices that aren't class compliant need an individual driver and there might be access to the device's internal routing, as there is for some RME audio devices, when using the Linux's hdspmixer wich is similar to RME's totalmix, http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php. Monitoring without latency means, that you could route the input channels, directly to the output channels. IOW if you connect a microphone, you could listen to the unprocessed signal without latency, it's not the signal processed by your Linux machine. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
> > Please reply to the mailing list and don't top-post. > > That is probably a misunderstanding. The Presonus and the Focusrite 2nd > gen USB devices don't provide access to the device's internal routing > when using it with a Linux machine. They are class compliant and don't > need individual drivers. Sound devices that aren't class compliant need > an individual driver and there might be access to the device's internal > routing, as there is for some RME audio devices, when using the Linux's > hdspmixer wich is similar to RME's totalmix, > http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php. > > Monitoring without latency means, that you could route the input > channels, directly to the output channels. IOW if you connect a > microphone, you could listen to the unprocessed signal without latency, > it's not the signal processed by your Linux machine. > Thank you for the explanation. That answers most of my questions very nicely, even ones I havent asked yet. reply do not list the usergroup address but the poster so this will happen every now and then. It involves reply all then remove the to: address and cut and paste the cc (which is the group address) into to: it is the way the group software adds addresses. the group address should ideally be in the reply-to and not a cc, but I will do the abovementioned workaround. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Ralf Mardorf
My last question.
Thank you for helping so far. I see there is development going for AVB using Intel I210 NIC "https://sourceforge.net/projects/open-avb/" and "https://github.com/AVnu/OpenAvnu" I know I can ask there, but it would be better to know from the Jack perspective as the buck most likely stops here before it can be deemed useful. Is the development of AVB on Linux that far down the road that the Jack Developers can work with AVB ? Also what is your prospects for when it might come available. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Hi,
some users shared experiences at the Linux Audio User mailing list, see https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB. Consider to read those threads and if you should still have questions after reading, to subscribe to the Linux Audio User mailing list and to send a request to this list, https://lists.linuxaudio.org/listinfo/linux-audio-user. Regards, Ralf _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
Hi,
in our research project we are implementing a JACK AVB Interface. I presented it on the last Linux Audio Conference: http://lac.linuxaudio.org/2018/pages/event/43/ https://media.ccc.de/v/lac2018-43-software_architecture_for_a_multiple_avb_listener_and_talker_scenario Best, Ck On 12/08/2018 09:32 AM, Ralf Mardorf wrote: > Hi, > > some users shared experiences at the Linux Audio User mailing list, see > https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB. > > Consider to read those threads and if you should still have questions > after reading, to subscribe to the Linux Audio User mailing list and to > send a request to this list, > https://lists.linuxaudio.org/listinfo/linux-audio-user. > > Regards, > Ralf > _______________________________________________ > Jack-Devel mailing list > [hidden email] > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org > Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.
On 12/08/2018 02:35 PM, Christoph Kuhr wrote: > Hi, > > in our research project we are implementing a JACK AVB Interface. > I presented it on the last Linux Audio Conference: > > http://lac.linuxaudio.org/2018/pages/event/43/ > > https://media.ccc.de/v/lac2018-43-software_architecture_for_a_multiple_avb_listener_and_talker_scenario > > > > Best, > Ck > > > On 12/08/2018 09:32 AM, Ralf Mardorf wrote: >> Hi, >> >> some users shared experiences at the Linux Audio User mailing list, see >> https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB. >> >> Consider to read those threads and if you should still have questions >> after reading, to subscribe to the Linux Audio User mailing list and to >> send a request to this list, >> https://lists.linuxaudio.org/listinfo/linux-audio-user. >> >> Regards, >> Ralf >> _______________________________________________ >> Jack-Devel mailing list >> [hidden email] >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org >> > _______________________________________________ > Jack-Devel mailing list > [hidden email] > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On 2018-12-08 08:37, Christoph Kuhr wrote:
> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend. > Thanks all for the response, it helped me a lot to make the right decissions. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Ralf Mardorf
Ralf Mardorf <[hidden email]> writes:
> That is probably a misunderstanding. The Presonus and the Focusrite > 2nd gen USB devices don't provide access to the device's internal > routing when using it with a Linux machine. They are class compliant > and don't need individual drivers. Sound devices that aren't class > compliant need an individual driver and there might be access to the > device's internal routing, as there is for some RME audio devices, > when using the Linux's hdspmixer wich is similar to RME's totalmix, > http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php. > > Monitoring without latency means, that you could route the input > channels, directly to the output channels. IOW if you connect a > microphone, you could listen to the unprocessed signal without > latency, it's not the signal processed by your Linux machine. It's not entirely without latency since sample acquisition and downsampling and interpolation filtering take its time as well, as to the actual mixing and then going back into the analog domain with similar measures. I think it's in the order of 2ms of latency you have to take into account. It's not a lot but it certainly is latency. -- David Kastrup _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On Tue, December 11, 2018 10:05 am, David Kastrup wrote:
> Ralf Mardorf <[hidden email]> writes: >> Monitoring without latency means, that you could route the input >> channels, directly to the output channels. > It's not entirely without latency since sample acquisition and > downsampling and interpolation filtering take its time as well, as to > the actual mixing and then going back into the analog domain with > similar measures. There are some interfaces which have an analog mixer on an output so that you can mix the input signal and the returned signal from the computer interface directly in the analog domain. The only latency on the input side is analog propagation delay, which is usually not worth discussing in an audio context. That style of interface can be really convenient for portable setups where you don't want to carry a mixer or monitor controller with you. -- Chris Caudle _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Christoph Kuhr
I thought it was the last of my questions but I have two more, of this
is the first mail. My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you configure it to 96000Hz with the windows mixer. It seems as soon as you close down the windows based presonus audiobox software it defaults back to 44100Hz and soesnt keep it in memory when you use it on Linux. Questions: 1) I need to confirm the above. Is there any way jack can report the bitrate of the data it receives from usb driver and therefore the bitrate by which the presonus 1818vsl send the data. 2) If the 1818vsl does revert back after a windows config at a higher rate, is there any current facility in jack to configure the presonus to work with 96000Hz ? _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Christoph Kuhr
I could not find a solution online for such a trivial matter, therefore
my question here. jackd is not a service as I tried to stop and start it with service jackd stop/start and it reports no such service Therefore it seems the only way to stop jackd is with kill -9 <pid> That would be fine, but there is no such process jackd when i do ps. # ps -A |grep -i jack 2905 ? 00:01:02 jackdbus There is is only jackdbus which must be something else. I can see that ardour/mixbus calls jackd with parameters at startup, but if I manually try to start jackd it says it is already running .... but it has no PID. So is it a runaway process on my system. jack disappears often and I have to reboot to get it back, obviously want to avoid that if I can stop and start it cleanly, or preferably reset it cleanly erasing all lock files if any exists etc. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: Bitrate from Jack or USB driver
|
|
In reply to this post by liebrecht
On 12/14/18 8:47 AM, [hidden email] wrote:
> I thought it was the last of my questions but I have two more, of this > is the first mail. > > My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you > configure it to 96000Hz with the windows mixer. > It seems as soon as you close down the windows based presonus audiobox > software it defaults back to 44100Hz and soesnt keep it in memory when > you use it on Linux. > > Questions: > 1) I need to confirm the above. I don't have this issue. The device works fine at 44.1k and 48k. I don't use it at 96k. I dimly recall users reporting various issues on Linux after using the 1717VSL on windows once, which resulted in a broken firmware update. That was 2013-ish though. IIRC the solution was flashing the firmware. That was reported on LAU or LAD. If you still have access to a windows box, update the firmware as described at https://answers.presonus.com/17746/cannot-switch-samplerates-audiobox-1818vsl > Is there any way jack can report the bitrate of the data it receives > from usb driver [..] Probably not. Jack facilitates inter-application communication in userspace. Hardware I/O on Linux happens at lower level. you can try https://community.ardour.org/files/adevices.sh which probes /proc/asound/ Cheers! robin _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
Re: Bitrate from Jack or USB driver
|
|
In reply to this post by liebrecht
On Fri, December 14, 2018 1:47 am, [hidden email] wrote:
> My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you > configure it to 96000Hz with the windows mixer. > It seems as soon as you close down the windows based presonus audiobox > software it defaults back to 44100Hz and doesn't keep it in memory when > you use it on Linux. Most USB devices will use whatever the driver requests if possible. The driver will request whatever the application which opens the ALSA driver requests if the driver accepts the request as supported by the card (USB devices return a parameter list which shows what rates are supported). > Questions: > 1) I need to confirm the above. > Is there any way jack can report the bitrate of the data it receives > from usb driver and therefore the bitrate by which the presonus 1818vsl > send the data. Check the /proc/asound/ entry for your card. See below, in my case it was card0/pcm0p/info, depending on your card configuration it may be something other than card0 and pcm0. The script that Robin mentioned will dump that info for you. > 2) If the 1818vsl does revert back after a windows config at a higher > rate, is there any current facility in jack to configure the presonus to > work with 96000Hz ? Sure, just specify what sample rate you want to use when you start jackd and it will send that request to the ALSA driver, which should send that request to the hardware. Startup with 48k requested: $ jackd -dalsa -dhw:Lambda -r48000 jackdmp 1.9.12 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|1024|2|48000|0|0|nomon|swmeter|-|32bit configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format Startup with 44.1k requested: $ jackd -dalsa -dhw:Lambda -r44100 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|1024|2|44100|0|0|nomon|swmeter|-|32bit configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format Startup with 96k requested (note this is not supported, so defaults to closest supported value, which in this case is 48k): $ jackd -dalsa -dhw:Lambda -r96000 ...startup messages, copyright, blah blah... Acquire audio card Audio0 creating alsa driver ... hw:Lambda|hw:Lambda|1024|2|96000|0|0|nomon|swmeter|-|32bit configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods ALSA: final selected sample format for capture: 24bit little-endian in 3bytes format Note that jackd does not warn the rates do not match, which is not what I expected. $ cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_3LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 1024 buffer_size: 2048 I thought that the ALSA driver would return the value of the actual sample rate used, and jackd would check that and display if the rate in use did not match the requested rate. Apparently not, at least not for all cards, maybe driver dependent. -- Chris Caudle _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by liebrecht
On Fri, December 14, 2018 2:11 am, [hidden email] wrote:
> jackd is not a service as I tried to stop and start it with > service jackd stop/start and it reports no such service Correct, it is a userspace application that needs to be started under your user account. Applications using jackd for routing have to be able to share a memory buffer, so you cannot for example run jackd as a system service that any or multiple users could use. > Therefore it seems the only way to stop jackd is with > kill -9 <pid> If you start from a command line you can use control-c key combination. Often users start from the qjackcontrol application, the application has a "stop" button which can be used to stop jackd. I also have my qjackcontrol set to run "killall jackd" on exiting just in case the jackd process hung for some reason and did not respond to control commands, but I have not actually seen that happen, it is just a precaution. Look in your applications directory, probably /usr/bin on most distributions, might be in /bin on some. There should be several apps with jack in the name. These could be useful to you: /usr/bin/jack_connect /usr/bin/jack_control /usr/bin/jack_disconnect /usr/bin/jack_lsp /usr/bin/jack_samplerate /usr/bin/jack_server_control > That would be fine, but there is no such process jackd when i do ps. > # ps -A |grep -i jack > 2905 ? 00:01:02 jackdbus > > There is is only jackdbus which must be something else. There are two variants of what is called version 2 of jackd, stand alone jackd and jackdbus, which is jackd which exposes dbus controls. For various historical reasons what I called version 2 of jackd is not really a continuation of version 1, it is another implementation of the same userspace API with a completely different engine. It started as an experiment to try out some different features, but jackd 1 and jackd 2 ended up continuing in parallel, with slightly different internal features, but same API presented to applications. Since you have jackdbus on your system that indicates your distribution ships jackd 2. The jackdbus application is started using dbus, if you attempt to start it manually it gives a warning: jackdbus should be auto-executed by D-Bus message bus daemon. If you want to run it manually anyway, specify "auto" as only parameter Probably some application automatically started jackdbus when you started the application. Hard to know which one that would have been. > I can see that ardour/mixbus calls jackd with parameters at startup, but > if I manually try to start jackd it says it is already running .... but > it has no PID. So is it a runaway process on my system. More probably jackd detects that there is already a process providing jack API services, in your case jackdbus. Use jack_control to query the parameters, stop, etc. > jack disappears often and I have to reboot to get it back You do not really have to reboot, if your system is configured to use jackdbus then just start an application which needs jackd and it will be automatically started, or use jack_control start to start it manually. Which distribution are you using? You should be able to configure your system to use jackd instead of jackdbus. If you manually start jackd from a terminal before starting any audio applications then jackdbus should detect that another jackd server is running and not start, but you can probably configure the audio applications to start jackd instead of jackdbus if you would prefer. Can you check what is in the ~/.jackdrc file? (by the way, not sure how familiar you are with linux terminal use, just reply if something is unclear, e.g. "~" means your user home directory). Possibly either that file, or a system file in /etc/jackdrc is configured to use jackdbus as the default jack server. My drc file has this for example: /usr/bin/jackd -P70 -t2000 -dalsa -dhw:Lambda -r48000 -p1024 -n3 -zt -I376 -O376 That indicates to applications that want to automatically start a jack server that my preference is jackd (instead of jackdbus), 2000 millisecond timeout for applications to respond, ALSA driver backend, my Lambda audio interface, 48k sample rate, 1024 samples per period, 3 periods buffering latency, use triangular PDF dither, and report 376 samples of input and output latency. You do not have to set all of those backend parameters, you may be able to get away with defaults for some. I doubt you will care about the differences between jackd and jackdbus though after finding jack_control, it sounds like you just have not experimented enough to find all the various jack application yet. Admittedly they are not documented very well. I'm not sure jackdbus is documented anywhere in an easy to find form, the jack website just has man pages for jackd, which has probably contributed to your confusion: https://github.com/jackaudio/jackaudio.github.com/wiki/jackd(1) https://github.com/jackaudio/jackaudio.github.com/wiki/jackdrc%285%29 The jack_control wiki page is probably the only place that mentions jackdbus: https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_jack_control -- Chris Caudle _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
In reply to this post by Christoph Kuhr
On 12/8/18 2:37 PM, Christoph Kuhr wrote:
> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend. I would say that for now, if you need to speak AVB, the easiest path is to get a recent MOTU USB class-compliant device with an AVB port. That way, the Linux system only needs to concern itself with the USB audio part, and the routing in the MOTU connects you to the AVB world. Thankfully, after being quite useless for open-source for many many years, they've now made two good decisions: * USB class compliance, and * the masterstroke, i.e. implementing the mixer as a web server that can be accessed via any browser, thus relieving open-source developers of the tedious task of reverse-engineering a mixer that will then only work on one particular device. Christoph, would you agree, or can people who do not frequent the same circles of hell as you are so competently doing consider "native" AVB yet? I've been lurking, but mostly been very, very afraid :) -- Jörn Nettingsmeier Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT http://stackingdwarves.net _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
|
|
On 2018-12-22 15:40, Jörn Nettingsmeier wrote:
> On 12/8/18 2:37 PM, Christoph Kuhr wrote: >> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend. > > I would say that for now, if you need to speak AVB, the easiest path > is to get a recent MOTU USB class-compliant device with an AVB port. > That way, the Linux system only needs to concern itself with the USB > audio part, and the routing in the MOTU connects you to the AVB world. > Thankfully, after being quite useless for open-source for many many > years, they've now made two good decisions: > * USB class compliance, and > * the masterstroke, i.e. implementing the mixer as a web server that > can be accessed via any browser, thus relieving open-source developers > of the tedious task of reverse-engineering a mixer that will then only > work on one particular device. > > Christoph, would you agree, or can people who do not frequent the same > circles of hell as you are so competently doing consider "native" AVB > yet? I've been lurking, but mostly been very, very afraid :) That is in fact the exact way I am going after long information gathering. Motu is the way to go, separate stage mixer with user config monitoring, independent from web based <1ms web based mixer, and the USB compliant io you can use to record with mixbus etc (arrives at your USB interface on PC at about 1ms latency. I am getting a B16 stagemixer and the AVB/USB interface. Pricey, but it solves about every problem I had and then some. I am selling off my Presonus and Steinberg gear. I really loved Steinberg, but the outright disregard for Linux that in my opinion exists at these companies makes it not palatable to own anymore. Presonus hardware in my opinion are great, but it is severely limited with little help when you ask to address the limitations which it was advertised as differently. Just wish there were a mixbus mixer in one of these stagemixers. I have gone through all the options and Motu it is the only one standing. the responses I got from other manufacturers ranged from the comical to outright ignorance of what users need. I have a feeling that AVB/IEEE will win over the ultranet stuff from Sony that is now licvensed out to someone handling it. that looks like a disaster to me. I am not going to invest in an interface that Sony the inventor did not want to pursue, it means that the profit margin must be about zero. We have unfortunaltely a bit of VHS vs Betamax again with AVB vs Ultranet, but I sure find AVB the better horse to bet on. _______________________________________________ Jack-Devel mailing list [hidden email] http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org |
«
Return to Jackit
|
1 view|%1 views
| Free forum by Nabble | Edit this page |