[Jack-Devel] Jack and thunderbolt

classic Classic list List threaded Threaded
169 messages Options
12345 ... 9
Reply | Threaded
Open this post in threaded view
|

Re: AVB

liebrecht
Correction to my mail:
I think I meant Ultramac not ultranet was the Sony invention licensed
out, anyway, I quoted from memory so it might not be right, but I gave
up on those protocols over AVB.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Sudden Pulseaudio Faulure reported due to jack

liebrecht
In reply to this post by Jörn Nettingsmeier-5
I cannot get answers on general usergroups about this error.
Pulseaudio fails with the well known grays screen of death when you open
mixer in pavucontrol.

"http://i.imgur.com/dIW5uul.png"

Running pulseaudio -vv I print the error containing excerpt of -vv which
seems to point to jack.

$] pulseaudio -vv

I: [pulseaudio] module.c: Loaded "module-role-cork" (index: #20;
argument: "").
I: [pulseaudio] module.c: Loaded "module-filter-heuristics" (index: #21;
argument: "").
I: [pulseaudio] module.c: Loaded "module-filter-apply" (index: #22;
argument: "").
W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to server
socket err = No such file or directory<
W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to server
request channel<
X11 connection rejected because of wrong authentication.
Connection Error (/usr/bin/dbus-launch terminated abnormally with the
following error: Autolaunch error: X11 initialization failed.
)
W: [pulseaudio] module-jack-sink.c: JACK error >jack server is not
running or cannot be started<
W: [pulseaudio] module-jack-sink.c: JACK error
 >JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock<
W: [pulseaudio] module-jack-sink.c: JACK error
 >JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock<
E: [pulseaudio] module-jack-sink.c: jack_client_open() failed.
E: [pulseaudio] module.c: Failed to load module "module-jack-sink"
(argument: ""): initialization failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.
I: [pulseaudio] module.c: Unloading "module-filter-apply" (index: #22).

Any idea how to fix this?
It all started with bluetooth audio.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Sudden Pulseaudio Faulure reported due to jack

Chris Caudle
On Sun, December 23, 2018 2:27 am, [hidden email] wrote:
> W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to server
> socket err = No such file or directory<
> W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to server
> request channel<

Do you need jackd and jack-sink module running at that point?  I am not
sure I understand from your question if you want the jack-sink feature
running automatically when you start, or if you only want PulseAudio to
not crash.
If the latter then there should be a configuration file setting that is
causing the jack-sink module to be loaded, you should able to remove that
setting.

In the fedora default configuration file for pulse, it checks to see if
jackd is present before loading the module:

### Automatically connect sink and source if JACK server is present
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif

I cannot tell from the error messages whether the problem is jackd is not
running when expected, or if jackd is running but for some reason Pulse
cannot make a connection.
--
Chris Caudle




_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Sudden Pulseaudio Faulure reported due to jack

liebrecht


On 2018-12-23 14:01, Chris Caudle wrote:

> On Sun, December 23, 2018 2:27 am, [hidden email]
> wrote:
>> W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to
>> server
>> socket err = No such file or directory<
>> W: [pulseaudio] module-jack-sink.c: JACK error >Cannot connect to
>> server
>> request channel<
>
> Do you need jackd and jack-sink module running at that point?  I am not
> sure I understand from your question if you want the jack-sink feature
> running automatically when you start, or if you only want PulseAudio to
> not crash.
> If the latter then there should be a configuration file setting that is
> causing the jack-sink module to be loaded, you should able to remove
> that
> setting.
>
> In the fedora default configuration file for pulse, it checks to see if
> jackd is present before loading the module:
>
> ### Automatically connect sink and source if JACK server is present
> .ifexists module-jackdbus-detect.so
> .nofail
> load-module module-jackdbus-detect channels=2
> .fail
> .endif
>
> I cannot tell from the error messages whether the problem is jackd is
> not
> running when expected, or if jackd is running but for some reason Pulse
> cannot make a connection.

Chris, thank you for your kind response.

I have severe problem trying to understand how to start up all these
sound servers to make everything work.
My setup is as follows.

(I will not discuss the sound output, lets just say that jack works fine
routing sound to my output device (e.g.181vsl or Motu B16) with
monitors) I will refer to that output as "routed to/by jack" below

1) I primarily want to use Mixbus (with Jack) (which worked absolutely
great since recently)
For that it seemed I needed the jackbus/jackd/jack-sinc. It worked fine
with those installed and started.
But it is an undocumented circus starting everything in the right order.

2) I need to run bluetooth sound from ipads and they need to be routed
through jack, but it seems bluez to be using the pulseaudio system
mixer.

3) I want to run the system sounds as generated by other sound
applications also to be routed with jack, but since that is the
pulseaudio mixer that should work fine (2) above works.

4) I have a virtual machine with Windows 7 running all my legacy window$
software.
I want to have the sound from the virtualmachine also routed by jack.


The problems I picked up along the way is squarely nonconsistent
problems with pulseaudio complaining about jack.
Add to that the imho unneccessary trouble with alsa you have a perfect
storm brewing between
ALSA/Pulseaudio/jackd/jackbus/jack-sync.
I am not a fan of alsa and prefer jack by far. At least Jack is
consistent.
I tried to work through manuals about each individually but there is no
consistent document available how to start these daemons in a way/order
that everything works.
It really is chaotic and a bit nomansland.

So, now to your questions.
--------------------------
> Do you need jackd and jack-sink module running at that point?  I am not
> sure I understand from your question if you want the jack-sink feature
> running automatically when you start, or if you only want PulseAudio to
> not crash.

Im not sure to answer this one as there is no consistent reason to start
any of them in any order I could find. I could not figure out from
documentation how these daemons actually work with each other. An
interactive diagram would have been great.
So in short to your answer, no, I dont care what the order is they must
be started, as long as I can get 1-4 all working.
The loading of the jack-sync module is a prerequisite from the Mixbus
posts I read. It seems to work gret for Mixbus only and causes havoc for
all other trying to work with pulseaudio/jack

I am using AVLinux which is Debian9 Stretch.

I cannot edit config files if I dont know how all these
pulseaudio/jack/alsa daemons interact.
Therefore,
Do you have a suggestion how I should approach the startup of these
daemons.
I would think I must first get bluetooth sound to work with pulseaudio,
then start the various jack daemons.
Where alsa fits in is crapshoot, but I pretty much just want it to do
the communication with the 1818vsl (which is what I gathered it is
doing)  and stay out of everything else where it cant do damage.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Christoph Kuhr
In reply to this post by liebrecht
Hey all,

until now, I have to admit, I never heard of Sonys solution. And I don't think it will become relevant.

The following is my opinion, fuled by some presentations and discussions from the last AES convention.

AES67 + ST2110
vs.
AVB
are Beta vs VHS in my opinion.

Dante will be overcome as soon as people realize, that point to point connections are obsolete and open standards are better suited for such endevours.
A transformation of the mindset is required and slowly coming.

However, Meyersound, L'Acoustics and d&b Audio have set AVB as the standard for sound reinforcement systems. done.
AVB has become the standard for automotive networking as well. done.

AES67 is not specified for IPv6. With the stupidest of all explanations: we don't need it.
AVB is agnostic to it, because it is layer 2. Yes, you would need an IPv6 gateway...

AVB takes so long to get to the market, because it is trying to provide the best solution for packet based networks. That requires hardware support, which is not that trivial. AES67 is just some solution among others, this is a relabeled set of VoIP standards with some extensions (without proper standardized discovery mechanisms (SAP, ZeroConf, or whatever...) - why specifying AES67, when interoperability is not the goal???).
AVB provides deterministic networking! you know what will happen!
But this results in long development of reliable equipment, that conforms to the standards.
Interoperability was also a big issue for AVB, but the MILAN protocol handles this now.

But for educational purposes, AES67 is the best way to learn about Audio over IP. You can actually use VLC.

My 50 cents...

BR,
Ck

Am 23. Dezember 2018 01:40:17 MEZ schrieb [hidden email]:
Correction to my mail:
I think I meant Ultramac not ultranet was the Sony invention licensed
out, anyway, I quoted from memory so it might not be right, but I gave
up on those protocols over AVB.
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Sudden Pulseaudio Faulure reported due to jack

Nedko Arnaudov
In reply to this post by liebrecht
>> I cannot tell from the error messages whether the problem is jackd
>> is not
>> running when expected, or if jackd is running but for some reason Pulse
>> cannot make a connection.

The history of calling both jackd and jackdbus jack servers "jackd" did
not make things clearer. Naming of module-jackdbus-detect.so already
suggests that PulseAudio uses shared library to communicate with
jackdbus (not jackd) and detect something (whether jack server in
jackdbus is running). Whether suggestion is a fact or not is best
checked in the source code, when documentation is not available.

> I am using AVLinux which is Debian9 Stretch.
>
> I cannot edit config files if I dont know how all these
> pulseaudio/jack/alsa daemons interact.

IIRC the information used to be in the jackaudio.org trac wiki.
Maybe someone else on this list knows if the trac wiki is still
accessible somehow.

> Therefore,
> Do you have a suggestion how I should approach the startup of these
> daemons.

To my knowledge PulseAudio works better with jackdbus over D-Bus
than with jackd. I'm even surprised it works at all with jackd. After
all jackdbus is "jack server" that can be autolaunched, controlled and
monitored over D-Bus :)

When D-Bus was introduced to jackd, it was only for reservation protocol
used for coordination (with PulseAudio) of audio device ownership/use.
The purpose of this reservation protocol is/was to allow jack server
take audio device ownership from PulseAudio.

In contrast, jackdbus exposes jack server control API over D-Bus and
also uses the audio device reservation protocol (which also works over
D-Bus).

PulseAudio (still?) uses the jackdbus control API.

Also, systems with both jackdbus and jackd executables, while possible,
are more complex to setup than ones with jackd or jackdbus only and at
least some of linux distros keep proving this for years.

Another common issue with such complex setups comes from the fact that
libjack.so that is used by JACK applications, can autostart the jack
server. libjack.so (source) code can autostart jack server in
jackd or in jackdbus but which one is proper depends on particular
system setup.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

liebrecht
In reply to this post by Ralf Mardorf
Thank you Christoph.

Stellar summary that can be of use to many and most importantly
arguments concisely expressed.

Exactly as I see it, but did not formulate it as well as you did.

This post has been a great help to me and definitely settles the choice
I will make thanks.




Christoph Kuhr wrote:

> Hey all,
>
> until now, I have to admit, I never heard of Sonys solution. And I
> don't
> think it will become relevant.
>
> The following is my opinion, fuled by some presentations and
> discussions
> from the last AES convention.
>
> AES67 + ST2110
> vs.
> AVB
> are Beta vs VHS in my opinion.
>
> Dante will be overcome as soon as people realize, that point to point
> connections are obsolete and open standards are better suited for such
> endevours.
> A transformation of the mindset is required and slowly coming.
>
> However, Meyersound, L'Acoustics and d&b Audio have set AVB as the
> standard for sound reinforcement systems. done.
> AVB has become the standard for automotive networking as well. done.
>
> AES67 is not specified for IPv6. With the stupidest of all
> explanations:
> we don't need it.
> AVB is agnostic to it, because it is layer 2. Yes, you would need an
> IPv6 gateway...
>
> AVB takes so long to get to the market, because it is trying to provide
> the best solution for packet based networks. That requires hardware
> support, which is not that trivial. AES67 is just some solution among
> others, this is a relabeled set of VoIP standards with some extensions
> (without proper standardized discovery mechanisms (SAP, ZeroConf, or
> whatever...) - why specifying AES67, when interoperability is not the
> goal???).
> AVB provides deterministic networking! you know what will happen!
> But this results in long development of reliable equipment, that
> conforms to the standards.
> Interoperability was also a big issue for AVB, but the MILAN protocol
> handles this now.
>
> But for educational purposes, AES67 is the best way to learn about
> Audio
> over IP. You can actually use VLC.
>
> My 50 cents...
>
> BR,
> Ck
>
> Am 23. Dezember 2018 01:40:17 MEZ schrieb
> [hidden email]:
>
>     Correction to my mail:
>     I think I meant Ultramac not ultranet was the Sony invention
> licensed
>     out, anyway, I quoted from memory so it might not be right, but I
> gave
>     up on those protocols over AVB.
>    
> ------------------------------------------------------------------------
>     Jack-Devel mailing list
>     [hidden email]
>     http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Sudden Pulseaudio Faulure reported due to jack

Holger Marzen
In reply to this post by Nedko Arnaudov
On Fri, 28 Dec 2018, Nedko Arnaudov wrote:

> > Therefore,
> > Do you have a suggestion how I should approach the startup of these
> > daemons.
>
> To my knowledge PulseAudio works better with jackdbus over D-Bus
> than with jackd. I'm even surprised it works at all with jackd. After
> all jackdbus is "jack server" that can be autolaunched, controlled and
> monitored over D-Bus :)

Not true. For years I have the same setup on different Linux computers:

- "autospawn = no" in /etc/pulse/client.conf
- "load-module module-jack-source" and "load-module module-jack-sink" in
  /etc/pulse/default.pa
- A shell script running under my userid started by my desktop
  environment that starts jackd and then pulseaudio
  (Alternatively you can start qjackctl that starts jackd and
  pulseaudio)

That means jack is my main audio system and always active. Pulseaudio is
always active, too.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Sudden Pulseaudio Faulure reported due to jack

Chris Caudle
In reply to this post by Nedko Arnaudov
On Thu, December 27, 2018 5:00 pm, Nedko Arnaudov wrote:
> To my knowledge PulseAudio works better with jackdbus over D-Bus
> than with jackd. I'm even surprised it works at all with jackd.

I am not sure if Fedora modifies the pulse configuration from the upstream
defaults, but for quite a few releases now the pulse installed by fedora
will give up access to the ALSA device without complaint when I start
jackd.
I looked in the system config file, and it does have some kind of jackdbus
detection module, but that must only take effect of jackdbus is actually
running, I have never seen it start jackdbus unprompted.
That does leave pulse in the original state, which is with no jack-sink
module loaded, but that is easy enough to load by hand when wanted.

It seems from the configuration file that if jackdbus is already running
when pulse starts that it should detect that and load jack-sink and
jack-source modules.  I'm not sure which configuration starts pulse at
login, so I'm not really confident of the place to modify if for example
you wanted to add a "jack_control start; jack_wait" command in the startup
sequence before pulse was started.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Fernando Lopez-Lezcano
In reply to this post by Jörn Nettingsmeier-5
On 12/22/18 12:40 PM, 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,

Yup, that is exactly why I was able to use Motu in my latest systems in
the fashion you suggest (out small Stage concert hall now has a 56.8
system, and our 3D 22.4 Listening Room has new speakers and Motu based
control system).

Class compliance vs linux comes with some caveats (at least in my
experience)...

If you need more than 24 channels (I use the 64 channel mode) you need
to downgrade your card to firmware 1.2.8+ (this is true for the 16A,
24Ao/Ai and 8M, AFAIK). 1.2.9 onwards does away with that mode so you
are restricted to 24 channels max in class compliant mode (which may not
be a problem for most users).

Even then I found problems with the latest firmware version, input
channels would shift in blocks of 8 every few seconds (ie: input coming
in through channel 1 would suddenly appear in 9, and so on and so
forth). Again, downgrading a bit gets rid of that problem.

So, not so nice. Firmware giveth, firmare taketh away (with no warning)...

The story does not end there, there are conditions in which changing
load in the Linux computer has effects in the AVB domain, specially if
the Linux computer is pretty loaded (either a glitch, or the interface
starts making some low level buzzes or distortion every second, or so,
sometimes temporarily, sometimes it gets stuck in that mode). My latest
thinking is that the internal processor of the Motu interface must be
close to being fully used, so when there is some glitch in the timing of
the USB packets it affects the rest of the internal processing,
including AVB transport. Just doing some tests a couple of days ago,
seems to also depend on number of AVB streams being used. But this is
just speculation on my part, no facts (facts are overrated these days,
argh).

> 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.

Yes definitely very very nice.

You can even control most of the internals through http+JSON or OSC and
we do that to control the internal routing matrix and modes in our systems.

> 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 :)

I'm forever wanting to do the full AVB stack, never find the time. The
is now even a branch in the OpenAVnu project that apparently can use a
non-AVB ethernet interface. I did some tests a while back and managed to
get Linux to sync to an AVB Motu card, and the card would switch into
"AVB mode". Never went further than that.

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Jörn Nettingsmeier-5
[sorry for the late reply to this one, I missed it the first time...]

On 12/31/18 1:04 AM, Fernando Lopez-Lezcano wrote:

> Yup, that is exactly why I was able to use Motu in my latest systems in
> the fashion you suggest (out small Stage concert hall now has a 56.8
> system, and our 3D 22.4 Listening Room has new speakers and Motu based
> control system).
>
> Class compliance vs linux comes with some caveats (at least in my
> experience)...
>
> If you need more than 24 channels (I use the 64 channel mode) you need
> to downgrade your card to firmware 1.2.8+ (this is true for the 16A,
> 24Ao/Ai and 8M, AFAIK). 1.2.9 onwards does away with that mode so you
> are restricted to 24 channels max in class compliant mode (which may not
> be a problem for most users).

Thanks for that hint. I'm about to get a MOTU for myself, so that's
gonna be useful.

> Even then I found problems with the latest firmware version, input
> channels would shift in blocks of 8 every few seconds (ie: input coming
> in through channel 1 would suddenly appear in 9, and so on and so
> forth). Again, downgrading a bit gets rid of that problem.

Owwww. That sounds _very_ bad. I'm currently experiencing a similar
problem on a Raspberry Pi when trying to cram 8 channels through a
stereo I²S line, but I wouldn't have expected such things to come up in
professional equipment. Well, as long as there is a known-good firmware
version...

> So, not so nice. Firmware giveth, firmare taketh away (with no warning)...
>
> The story does not end there, there are conditions in which changing
> load in the Linux computer has effects in the AVB domain, specially if
> the Linux computer is pretty loaded (either a glitch, or the interface
> starts making some low level buzzes or distortion every second, or so,
> sometimes temporarily, sometimes it gets stuck in that mode). My latest
> thinking is that the internal processor of the Motu interface must be
> close to being fully used, so when there is some glitch in the timing of
> the USB packets it affects the rest of the internal processing,
> including AVB transport. Just doing some tests a couple of days ago,
> seems to also depend on number of AVB streams being used. But this is
> just speculation on my part, no facts (facts are overrated these days,
> argh).

Long as it feels truthy :-D

Do you know whether the different AVB MOTU boxes are all the same in the
way they handle AVB (as in, identical subsystem/firmware/drivers)? I'm
eyeing the one with eight mic preamps (MOTU 8 Pre-es)...

> Yes definitely very very nice.
>
> You can even control most of the internals through http+JSON or OSC and
> we do that to control the internal routing matrix and modes in our systems.

That's very good to know. Does it have a sane documented interface, or
are you basically reverse-engineering the mixer website?

>> 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 :)
>
> I'm forever wanting to do the full AVB stack, never find the time. The
> is now even a branch in the OpenAVnu project that apparently can use a
> non-AVB ethernet interface. I did some tests a while back and managed to
> get Linux to sync to an AVB Motu card, and the card would switch into
> "AVB mode". Never went further than that.

I've been lurking on the open-AVB list for a long time, nothing much
happened. Then I talked to an AVB guy with Meyer Sound at the last
Tonmeistertagung, they just renamed everything "Milan" and are seriously
getting off their asses now (probably panicking about the Dante camp
just having announced basic video capability). Loads of new products,
finally talk about cross-vendor interoperability and interesting
plugfests (they showed Meyer AVB gear talking to Shure wireless units
and some professional power amps by another brand). Let's hope some
crumbs fall into the land of free software.


All best,


Jörn


--
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
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Chris Caudle
On Sun, February 24, 2019 6:00 am, Jörn Nettingsmeier wrote:
> Let's hope some
> crumbs fall into the land of free software.

Someone on one of the Ardour forums mentioned an AVB ALSA driver, but as
of Friday no link to the driver. Haven't checked yet again this weekend,
hopefully that poster will provide a link to a repository with the ALSA
driver.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Fernando Lopez-Lezcano
In reply to this post by Jörn Nettingsmeier-5
On 2/24/19 4:00 AM, Jörn Nettingsmeier wrote:

> [sorry for the late reply to this one, I missed it the first time...]
>
> On 12/31/18 1:04 AM, Fernando Lopez-Lezcano wrote:
>> Yup, that is exactly why I was able to use Motu in my latest systems
>> in the fashion you suggest (out small Stage concert hall now has a
>> 56.8 system, and our 3D 22.4 Listening Room has new speakers and Motu
>> based control system).
>>
>> Class compliance vs linux comes with some caveats (at least in my
>> experience)...
>>
>> If you need more than 24 channels (I use the 64 channel mode) you need
>> to downgrade your card to firmware 1.2.8+ (this is true for the 16A,
>> 24Ao/Ai and 8M, AFAIK). 1.2.9 onwards does away with that mode so you
>> are restricted to 24 channels max in class compliant mode (which may
>> not be a problem for most users).
>
> Thanks for that hint. I'm about to get a MOTU for myself, so that's
> gonna be useful.
>
>> Even then I found problems with the latest firmware version, input
>> channels would shift in blocks of 8 every few seconds (ie: input
>> coming in through channel 1 would suddenly appear in 9, and so on and
>> so forth). Again, downgrading a bit gets rid of that problem.
>
> Owwww. That sounds _very_ bad.

Yup, not the best.

> I'm currently experiencing a similar
> problem on a Raspberry Pi when trying to cram 8 channels through a
> stereo I²S line,

Weird. Unrelated, right? How are you doing this, I presume you are not
going through an alsa driver? (I would be interested to know more, I'm
always interested in tiny computers that can drive many speakers or
sample many microphone capsules :-)

> but I wouldn't have expected such things to come up in
> professional equipment.

I imagine that would not happen if you were to use their proprietary
driver instead of the class compliant driver. In this case I did not
investigate much, I just downgraded and it seems to work (I have not
reported the bug). Probably our use case never gets tested.

> Well, as long as there is a known-good firmware
> version...

There is.

>> So, not so nice. Firmware giveth, firmare taketh away (with no
>> warning)...
>>
>> The story does not end there, there are conditions in which changing
>> load in the Linux computer has effects in the AVB domain, specially if
>> the Linux computer is pretty loaded (either a glitch, or the interface
>> starts making some low level buzzes or distortion every second, or so,
>> sometimes temporarily, sometimes it gets stuck in that mode). My
>> latest thinking ...

My latest _latest_ thinking says that what I said before is most likely
wrong (like so many times before, ha :-). I think the whole thing
happens on the Linux side, and is related to the USB interface. For
example, I had forgotten I was running jackd with "-s" (long story about
why that was there in the first place), once I removed that, things
started behaving better.

I just finished stabilizing our new setup in our renovated Listening
Room (you know the space :-), still 22 main speakers but now all Adams,
and 8 Dynaudio subs instead of the old 4 - much much better sound
quality. New (fanless) control computer redone from scratch, and an all
Motu setup for driving everything.

Looks like it is running stable, 24x7, days on end with no glitches.
Finally. The last problem was some kernel locking problem that
apparently was happening between Supernova (the multi-core aware
SuperCollider sound server) and aconnect of all things. I was calling
aconnect from SC to detect changes in connected midi peripherals and
sometimes this would (apparently) do bad things and the whole thing
would grind to a halt. I switched to monitoring midi through /proc/ and
that apparently did the trick.

> Do you know whether the different AVB MOTU boxes are all the same in the
> way they handle AVB (as in, identical subsystem/firmware/drivers)? I'm
> eyeing the one with eight mic preamps (MOTU 8 Pre-es)...

They all talk to each other as long as they are AVB (so far...). We do
have one MOTU 8M (the one w/8 mic preamps) in the Listening Room and it
is happy (we use its usb2 interface as the gateway into the system for
external laptops). It is connected through AVB to one 24Ai, one 24Ao and
a 16A which is where the control computer connects through USB). In the
Stage we have 8 MOTU cards talking to each other (+ 3 MOTU AVB switches).

>> You can even control most of the internals through http+JSON or OSC
>> and we do that to control the internal routing matrix and modes in our
>> systems.
>
> That's very good to know. Does it have a sane documented interface, or
> are you basically reverse-engineering the mixer website?

It is documented...

For OSC there is this (I have not tried osc):
https://cdn-data.motu.com/downloads/audio/AVB/docs/OSC%20Quick%20Reference.pdf

For http+JSON:
https://cdn-data.motu.com/downloads/audio/AVB/docs/MOTU%20AVB%20Web%20API.pdf

Carlos (sysadmin here) sort of reverse engineered how to get a full
preset from the data stream so we could capture those and resend them on
demand. We are using http+JSON (form SuperCollider) to both read
internal status (for example querying the master clock audio interface
to see if its clock has locked[*]) and to change stuff (for example
change the connection status of a crosspoint in the internal switching
matrix of an audio interface)

...
>> I'm forever wanting to do the full AVB stack, never find the time. The
>> is now even a branch in the OpenAVnu project that apparently can use a
>> non-AVB ethernet interface. I did some tests a while back and managed
>> to get Linux to sync to an AVB Motu card, and the card would switch
>> into "AVB mode". Never went further than that.
>
> I've been lurking on the open-AVB list for a long time, nothing much
> happened.

Same here, a few posts here and there that seem interesting but nothing
that solves the whole problem (which is complex).

> Then I talked to an AVB guy with Meyer Sound at the last
> Tonmeistertagung, they just renamed everything "Milan" and are seriously
> getting off their asses now (probably panicking about the Dante camp
> just having announced basic video capability). Loads of new products,
> finally talk about cross-vendor interoperability and interesting
> plugfests (they showed Meyer AVB gear talking to Shure wireless units
> and some professional power amps by another brand). Let's hope some
> crumbs fall into the land of free software.

Crossing fingers here... I'm itching to compile and start testing, no
time yet.

The MOTU is a reasonable option _now_ if you are aware of the caveats,
but I have not much faith in the future given my experience with their
firmware. At some point (hopefully very very far in the future) the
internal _hardware_ will change - probably sporting the very same model
number - and then we will not be able to downgrade firmware in really
new boxes (I have seen that in the UltraLite AVB I have, the really old
firmware versions for the card in their web site do not load in my
UltraLite). If what is lost is the 64 channel mode that I need then:
dead end again.

The best would be to talk AVB from Linux.

Or maybe reverse engineer their proprietary USB endpoints and adapt the
Linux USB driver to be able to handle those? Or clean-room
reverse-engineer Dante itself? Or be really _really_ smart and make
music that only needs one speaker! (or one microphone capsule). Mono and
Omni! YES!
:-P

-- Fernando


[*] nasty things happen otherwise, the MOTU takes 5 or 6 seconds to
stabilize its internal clock when switching sampling rates or when
_first_ using the interface after a reboot. ALSA sees the interface all
the time, and Jackd also sees it. But if you try to start Jackd while
the MOTU is not yet locked... Jackd starts but then fails when it
(maybe) realizes the card is not yet ready. If you are patient and wait
a few more seconds and then try again jackd starts just fine.

For fun: have pulseaudio running and set to 44.1KHz, try to start Jack
at 48KHz (and repeat if not successful)....

0: jackd starts, gets the card from pulseaudio
1: jackd switches the card to 48KHz (while starting)
2: jackd fails to start because the card is not yet ready (unlocked)
3: jackd gives the card back to pulseaudio as it quits
4: pulseaudio switches the card back to 44.1KHz
GOTO 0

Infinite loop!
Infinite fun!

More fun: have a MOTU card in 64 channel mode in a modern pulseaudio
environment (Fedora 28, for example). Pulseaudio does not like the card
as it has > 32 channels. It does NOT ignore the card. It thinks the card
will be better behaved magically in the very near future as it tries
again and again to use it (lots of messages in the logs). Jackd cannot
"borrow" the card from pulseaudio. Jackd cannot start on that card (tip:
I run out of patience so I just told pulse to ignore that card).

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Chris Caudle
On Sun, February 24, 2019 4:54 pm, Fernando Lopez-Lezcano wrote:
>>> Even then I found problems with the latest firmware version, input
>>> channels would shift in blocks of 8 every few seconds (ie: input
>>> coming in through channel 1 would suddenly appear in 9, and so on and
>>> so forth). Again, downgrading a bit gets rid of that problem.

> I imagine that would not happen if you were to use their proprietary
> driver instead of the class compliant driver.

Wouldn't Apple equipment be using a class compliant driver?  Given how
much of their business was traditionally to Apple users that seems very
strange that they would have firmware that breaks class compliant use if
it also broke usage on Mac OS and iOS. I guess Mac users only get the
lower channel count firmware?  But that is the same firmware you say
shifts the channels around, correct?

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Fernando Lopez-Lezcano
On 2/24/19 3:15 PM, Chris Caudle wrote:

> On Sun, February 24, 2019 4:54 pm, Fernando Lopez-Lezcano wrote:
>>>> Even then I found problems with the latest firmware version, input
>>>> channels would shift in blocks of 8 every few seconds (ie: input
>>>> coming in through channel 1 would suddenly appear in 9, and so on and
>>>> so forth). Again, downgrading a bit gets rid of that problem.
>
>> I imagine that would not happen if you were to use their proprietary
>> driver instead of the class compliant driver.
>
> Wouldn't Apple equipment be using a class compliant driver?  Given how
> much of their business was traditionally to Apple users that seems very
> strange that they would have firmware that breaks class compliant use if
> it also broke usage on Mac OS and iOS. I guess Mac users only get the
> lower channel count firmware?  But that is the same firmware you say
> shifts the channels around, correct?

Motu provides downloads of proprietary drivers for both Mac and Windows.

I have not used either of those two "exotic" platforms, but I'm pretty
sure that when using their proprietary driver on a Mac you would have
access to 64 channels over USB2 if the sample rate is limited to 44.1
and 48 KHz. Again, on a Mac you would also be able to use thunderbolt
for machines that have that, and Motu interfaces that have that, and
that will give you 128 channels (proprietary driver again).

If using the class compliant drivers, you would be limited to 24
channels (with the newest firmware).

Don't know about the channel shifting.

In any case, I don't know what a Mac would do without the proprietary
driver, maybe its own class compliant drivers would be just fine with
the class compliant USB endpoints of the Motu interfaces. Maybe not.

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

happy
In reply to this post by Chris Caudle

MOTU once told me that their http://motu.com/products/avb/avb-switch AVB switch should work with Linux.
Anyone had experience if all 32 channels @ 48KHz works with JACK and ALSA ?
I have some i210 cards and three 8 channel ADAT preamps  so would be eager to know before spending the $.
Still looking for an audio interface on Linux to support 24 to 32 channels @ 48Khz.

Thanks



On Mon, Feb 25, 2019 at 7:15 AM Chris Caudle <[hidden email]> wrote:
On Sun, February 24, 2019 4:54 pm, Fernando Lopez-Lezcano wrote:
>>> Even then I found problems with the latest firmware version, input
>>> channels would shift in blocks of 8 every few seconds (ie: input
>>> coming in through channel 1 would suddenly appear in 9, and so on and
>>> so forth). Again, downgrading a bit gets rid of that problem.

> I imagine that would not happen if you were to use their proprietary
> driver instead of the class compliant driver.

Wouldn't Apple equipment be using a class compliant driver?  Given how
much of their business was traditionally to Apple users that seems very
strange that they would have firmware that breaks class compliant use if
it also broke usage on Mac OS and iOS. I guess Mac users only get the
lower channel count firmware?  But that is the same firmware you say
shifts the channels around, correct?

--
Chris Caudle


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Jonathan Woithe-2
On Tue, Feb 26, 2019 at 01:06:46PM +0800, happy musicmaker wrote:
> Still looking for an audio interface on Linux to support 24 to 32 channels
> @ 48Khz.

I realise the form factor probably doesn't suit your use case, but the
Yamaha TF series mixers seem to work well as a recording source under Linux.
Sample rate is fixed at 48 kHz.  32 inputs (plus, I think, from memory, a
selectable stereo bus) are accessible via USB using the standard kernel
snd-usb class compliant driver.  The TF1 (16 pres and faders) and TF3 (24
pres and faders) would require the use of at least one Dante remote stagebox
to get a total of 32 pres.

Regards
  jonathan
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Fernando Lopez-Lezcano
In reply to this post by happy
On 2/25/19 9:06 PM, happy musicmaker wrote:
>
> MOTU once told me that their http://motu.com/products/avb/avb-switch AVB
> switch should work with Linux.

??
Their switch is just an ethernet switch that is AVB aware. It will work
with anything. For example, a Linux computer can connect to the Motu's
interfaces web server. It is ethernet.

> Anyone had experience if all 32 channels @ 48KHz works with JACK and ALSA ?

Have you been following the thread?

While you can send standard ethernet traffic through their switch, AVB
is something else. If you want to output or input AVB streams directly
from Linux you will need to do a lot of work (and please share it if you
do!). The openavnu repository would be a start but I don't know of
anyone that has a full stack working.

I managed (a long time ago) to get Linux to see a Motu interface and
sync with its clock but that was it, never got to streaming.

> I have some i210 cards and three 8 channel ADAT preamps  so would be
> eager to know before spending the $.
> Still looking for an audio interface on Linux to support 24 to 32
> channels @ 48Khz.

Is that input or output or both? Please read the thread in detail.

I have been using Motu AVB interfaces through USB2 and with up to 64
channels of I/O total (the computer connects through USB2 to the
interface, and if you need more I/O than what the directly attached Motu
interface can do you need to use more than one and bridge them with
AVB). 24 channels is relatively easy, more I/O channels requires having
the right sound interface _and_ the right firmware (an older version
than what ships today). I have used the 16A, 24Ai, 24Ao and others of
the same generation. You also need a properly tuned system, of course.

-- Fernando


> On Mon, Feb 25, 2019 at 7:15 AM Chris Caudle <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Sun, February 24, 2019 4:54 pm, Fernando Lopez-Lezcano wrote:
>      >>> Even then I found problems with the latest firmware version, input
>      >>> channels would shift in blocks of 8 every few seconds (ie: input
>      >>> coming in through channel 1 would suddenly appear in 9, and so
>     on and
>      >>> so forth). Again, downgrading a bit gets rid of that problem.
>
>      > I imagine that would not happen if you were to use their proprietary
>      > driver instead of the class compliant driver.
>
>     Wouldn't Apple equipment be using a class compliant driver?  Given how
>     much of their business was traditionally to Apple users that seems very
>     strange that they would have firmware that breaks class compliant use if
>     it also broke usage on Mac OS and iOS. I guess Mac users only get the
>     lower channel count firmware?  But that is the same firmware you say
>     shifts the channels around, correct?
>
>     --
>     Chris Caudle
>
>
>     _______________________________________________
>     Jack-Devel mailing list
>     [hidden email] <mailto:[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
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Chris Caudle
> The openavnu repository would be a start but I don't know of
> anyone that has a full stack working.

On a pretty long thread on the Ardour forums someone recently wrote this:
"The ALSA driver (based on the intel igb driver) can use any buffersize
down to a single interval.
"The lowest round trip latencies (analog to analog) on my 16A therefore
are 1.5ms at 6/48kHz to 0.75 ms at 24/192kHz measured with jack2 in
synchronous mode."

No response after several days to my request for a link to a repository
containing that ALSA driver.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Thomas Brand
On Tue, February 26, 2019 14:46, Chris Caudle wrote:

>> The openavnu repository would be a start but I don't know of
>> anyone that has a full stack working.
>
> On a pretty long thread on the Ardour forums someone recently wrote this:
>  "The ALSA driver (based on the intel igb driver) can use any buffersize
> down to a single interval. "The lowest round trip latencies (analog to
> analog) on my 16A therefore are 1.5ms at 6/48kHz to 0.75 ms at 24/192kHz
> measured with jack2 in synchronous mode."
>
> No response after several days to my request for a link to a repository
> containing that ALSA driver.
>

This looks like an AVB ALSA driver:

https://github.com/induarun9086/beagleboard-linux/blob/4.4/sound/drivers/avb.c

It's somewhat buried in another repo.

From what I read it was a GSoC project:
-----
This is the fourth instalment of the weekly report for the GSoC beagle
board AVB stack project. The plan was to start the design and
implementation of the audio driver and more specifically to start the
implementing the Stream reservation protocol of the AVB stack. The current
status and the upcoming tasks are listed below,

Status:

  -> Improvements are done for the clock synchronization for gPTP.
  -> Now I can see improved synchronization errors in the range of
hundreds of nanoseconds to some tens of micro seconds.
  -> Started to design the ALSA audio driver required to implement the AVB
streaming (using the synchronized clock).

Next Tasks:

  -> Start coding for the ALSA audio driver for AVB and setup a barebones
driver at first.
  -> Start implementing the Stream reservation protocol inside it to start
streaming.
  -> Setup the hardware required (audio cards) to output the streamed
audio via ethernet AVB to speakers.
------

Not sure how mature the driver is in its current state or if it's only
useful for BB.

Greetings
Thomas



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12345 ... 9