[Jack-Devel] Usage feasibility Q

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: ?==?utf-8?q? Usage feasibility Q

Ralf Mattes
Sorry, posted with wrong sender ...
 

Am Mittwoch, 31. Januar 2018 17:25 CET, "Ralf Mattes" <[hidden email]> schrieb:
 

>  
> Am Mittwoch, 31. Januar 2018 17:07 CET, Robert Bielik <[hidden email]> schrieb:
> > [...]
> > jackd   578   pi    3u   REG       0,16       12  11510 /dev/shm/jack_sem.1000_default_system (deleted)
> > jackd   578   pi    4u   CHR      116,0      0t0  11412 /dev/snd/controlC0
> > jackd   578   pi    5u  unix 0xb78a4380      0t0   8031 /dev/shm/jack_default_1000_0 type=STREAM
> > jackd   578   pi    6u   CHR     116,16      0t0  11413 /dev/snd/pcmC0D0p
> > jackd   578   pi    7u   CHR     116,24      0t0  11414 /dev/snd/pcmC0D0c
> > jackd   578   pi    8u  unix 0xb78a7b80      0t0   8033 type=STREAM> jackd   578   pi    9u   REG       0,16       12   8034 /dev/shm/jack_sem.1000_default_freewheel (deleted)
> > jackd   578   pi   10u  unix 0xb78a7800      0t0  11511 /dev/shm/jack_default_1000_0 type=STREAM
> > /home/pi/start_jack
> > Interesting to see the DEL for file descriptor.
>
> Well, that means that "someone" removed those files from the filesystem. Since the jackd process still
> hase the file descriptors open the files are still there, but since the have no name anymore they are
> inaccessible ...
> Now you only have to find out _who_ did it ;-.)
>  
>
> Cheers, RalfD
>
>
 
 
 
 


_______________________________________________
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: ?==?utf-8?q? Usage feasibility Q

Robert Bielik
> > Well, that means that "someone" removed those files from the filesystem.
> Since the jackd process still
> > hase the file descriptors open the files are still there, but since the have no
> name anymore they are
> > inaccessible ...
> > Now you only have to find out _who_ did it ;-.)

Since the "original" size of /dev/shm was too small for jack2, I've added this to /etc/fstab (ripped from somewhere on the net):

none    /dev/shm        tmpfs   defaults,size=128M      0       0

Might this be the problem ?

Regards
/R
_______________________________________________
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: Usage feasibility Q

Robert Bielik
In reply to this post by Ralf Mattes
> Looks like you don't have one. Maybe you can append '> /tmp/jackd.log
> 2>&1 ' to your jackd invocation
> in your '/home/pi/start_jack' script?

Ok, did so, but the log didn't reveal anything of use...

/R
_______________________________________________
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: ?==?utf-8?q? Usage feasibility Q

Robert Bielik
In reply to this post by Robert Bielik
>
> Since the "original" size of /dev/shm was too small for jack2, I've added this
> to /etc/fstab (ripped from somewhere on the net):
>
> none    /dev/shm        tmpfs   defaults,size=128M      0       0

Hmm... if I remove this line, the amount is ~464MB, so it was not needed from the start. Doesn't change anything though...

Regards
/Robert

_______________________________________________
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: ?==?utf-8?q? Usage feasibility Q

Robert Bielik
Solved! It seems to be a systemd setting!!

https://bbs.archlinux.org/viewtopic.php?pid=1487274#p1487274

By setting RemoteIPC=No in /etc/system.d/logind.conf it all seems to work now!

Regards
/Robert

> -----Original Message-----
> From: Robert Bielik
> Sent: den 31 januari 2018 17:58
> To: Robert Bielik <[hidden email]>; [hidden email]
> Subject: RE: [Jack-Devel] ?==?utf-8?q? Usage feasibility Q
>
> >
> > Since the "original" size of /dev/shm was too small for jack2, I've added this
> > to /etc/fstab (ripped from somewhere on the net):
> >
> > none    /dev/shm        tmpfs   defaults,size=128M      0       0
>
> Hmm... if I remove this line, the amount is ~464MB, so it was not needed
> from the start. Doesn't change anything though...
>
> Regards
> /Robert

_______________________________________________
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: Usage feasibility Q

Chris Caudle
In reply to this post by Robert Bielik
On Wed, January 31, 2018 9:30 am, Robert Bielik wrote:
> As shown here (I wrote that msg in the forum):

"You have been notified about this topic, please login to view it."

I don't really feel like going through the effort of creating a new
account on some web site I've never heard of to fix your problem.  If you
would like help on this mailing list then I recommend you send relevant
information to this mailing list.

> The files in /dev/shm aren't supposed to vanish during
> lifetime of jackd process, right ?

Not typically.
I found this in common/JackShmMem.cpp:

 jack_log("JackShmMem::delete size = %ld index = %ld", size, info.index);

So it seems like at least some shared memory operations get logged.
Maybe try -v for verbose logging.

--
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: Usage feasibility Q

Robert Bielik
> I don't really feel like going through the effort of creating a new
> account on some web site I've never heard of to fix your problem.  If you
> would like help on this mailing list then I recommend you send relevant
> information to this mailing list.

Ah, sorry about that, I thought it was publicly readable. My bad!

/R
_______________________________________________
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: ?==?utf-8?q? ?==?utf-8?q? ?= Usage feasibility

Ralf Mattes
In reply to this post by Robert Bielik
 
Am Mittwoch, 31. Januar 2018 18:11 CET, Robert Bielik <[hidden email]> schrieb:
 
> Solved! It seems to be a systemd setting!!

Oh dear! Here I have a reply mail sitting open on my desktop for quite a while since I wasn't shure
whether suggesting to look into systemd would be too rude (o.k. - my chosen language in that mail
is rather harsh). I remembered vaguely that stupid (imho) idea to kill all user-stated processes at logout
(way cool if you start a long-running simulation/analysis job over the weekend only to come back on
monday to find your job killed by systemd).
An extra set of facepalms goes to the systemd team for implementing a stoopid "feature" and then
doing even this completely wrong :-)
Sytemd is _not_ cleaning IPC at all (with ipcclean or ipcrm), it's removing the file system handle.
Nothing more. Isn't anyone terrified by trusting core system functinality into the hands of the
programmer equivalent of "Happy Tree Friends"?

<note-to-self>must remove this crap!</note-to-self>

Glad you fond it,

 RalfD

>
> https://bbs.archlinux.org/viewtopic.php?pid=1487274#p1487274
>
> By setting RemoteIPC=No in /etc/system.d/logind.conf it all seems to work now!
>
> Regards
> /Robert
>
> > -----Original Message-----
> > From: Robert Bielik
> > Sent: den 31 januari 2018 17:58
> > To: Robert Bielik <[hidden email]>; [hidden email]
> > Subject: RE: [Jack-Devel] ?==?utf-8?q? Usage feasibility Q
> >
> > >
> > > Since the "original" size of /dev/shm was too small for jack2, I've added this
> > > to /etc/fstab (ripped from somewhere on the net):
> > >
> > > none    /dev/shm        tmpfs   defaults,size=128M      0       0
> >
> > Hmm... if I remove this line, the amount is ~464MB, so it was not needed
> > from the start. Doesn't change anything though...
> >
> > Regards
> > /Robert
>
> _______________________________________________
> 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: ?= Usage feasibility

Robert Bielik
> Nothing more. Isn't anyone terrified by trusting core system functinality into
> the hands of the
> programmer equivalent of "Happy Tree Friends"?

Ah! A "Happy Tree Friend" friend!! 😝

Regards
/Robert

_______________________________________________
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: Usage feasibility Q

David Kastrup
In reply to this post by Chris Caudle
"Chris Caudle" <[hidden email]> writes:

> On Wed, January 31, 2018 9:33 am, Ralf Mattes wrote:
>> But the OP clearly stated that it worked during a ssh login. It's only
>> later on that it stops working.
>
> It works during the first ssh login, but not during subsequent logins.
> Screen would avoid that issue by never really closing down the user
> session.

Huh.  Perhaps start jackd with nohup ?  Maybe it reacts to a hangup
signal in some manner?

--
David Kastrup
_______________________________________________
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: Usage feasibility Q

David Kastrup
David Kastrup <[hidden email]> writes:

> "Chris Caudle" <[hidden email]> writes:
>
>> On Wed, January 31, 2018 9:33 am, Ralf Mattes wrote:
>>> But the OP clearly stated that it worked during a ssh login. It's only
>>> later on that it stops working.
>>
>> It works during the first ssh login, but not during subsequent logins.
>> Screen would avoid that issue by never really closing down the user
>> session.
>
> Huh.  Perhaps start jackd with nohup ?  Maybe it reacts to a hangup
> signal in some manner?

Never mind.  Saw in another answer that systemd's idea of ending a user
session is at fault.  IIRC, systemd even overrides an explicit nohup
anyway (WTF?!?).

--
David Kastrup
_______________________________________________
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: Usage feasibility Q

John Rigg-16
On Wed, Jan 31, 2018 at 09:19:09PM +0100, David Kastrup wrote:
> Never mind.  Saw in another answer that systemd's idea of ending a user
> session is at fault.  IIRC, systemd even overrides an explicit nohup
> anyway (WTF?!?).

This stuff makes me glad I'm still using sysvinit on my
Debian systems.

John
_______________________________________________
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: Usage feasibility Q

Chris Caudle
In reply to this post by David Kastrup
On Wed, January 31, 2018 2:19 pm, David Kastrup wrote:
> Never mind.  Saw in another answer that systemd's idea of ending a user
> session is at fault.  IIRC, systemd even overrides an explicit nohup
> anyway (WTF?!?).

I had forgotten, but after seeing the answer I remember when this came up
a couple of years ago, systemd proposed this behavior as a security
feature, some subset of users yelled about how it would break their usual
work flow that involved using nohup to keep jobs running in the background
when they logged out, so the behavior was made configurable but "secure by
default."  Obviously not many people make use of the configurability,
because when this comes up it takes a pretty deep google search to stumble
on the answer, seems hardly anyone remembers that systemd cleans out user
processes on exit now by default.

Might not be exactly the same, the article I remembered talks about that
behavior even killing screen, I think that was KillUserProcess instead of
the shared memory setting, but very similar:
https://www.phoronix.com/scan.php?page=news_item&px=systemd-230-KillUserProcesses

I think maybe the jack FAQ needs a section for headless use, it seems
about twice a year some problem comes up and it takes a few days to work
through all the variations of PAM and systemd caveats needed to get jack
working on an appliance style device.

--
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: Usage feasibility Q

Chris Caudle
In reply to this post by David Kastrup
On Wed, January 31, 2018 2:19 pm, David Kastrup wrote:
> Never mind.  Saw in another answer that systemd's idea of ending a user
> session is at fault.

One thing I don't quite get, according to the logind.conf man page, the
RemoveIPC setting as true will cause the shared resources to be removed
"when the user fully logs out," but does no define how "fully logs out" is
determined.  I would have thought that the user shell still running jackd
would cause "fully logged out" to evaluate to false.
Is there some quirk to how the shell is started from runuser that would
make logind determine the user was not actually logged in?  Maybe because
runuser was started from sudo and so did not login with a password?

--
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: Usage feasibility Q

Malik Costet
In reply to this post by Chris Caudle
On 2018-01-31 21:46, Chris Caudle wrote:
> <snip />
> I think maybe the jack FAQ needs a section for headless use, it seems
> about twice a year some problem comes up and it takes a few days to work
> through all the variations of PAM and systemd caveats needed to get jack
> working on an appliance style device.
>

That'd be lovely. FWIW, I've been playing with JACK on a Pi as well, and
ran into the dbus issue. Yes, it took quite some digging, some of it in
mailing list archives -- which won't be around forever, to get around it.

--
 M.
_______________________________________________
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: ?= Usage feasibility

Gaz Mellen
In reply to this post by Ralf Mattes
Hello All,
Does anyone know of someone who has a setup where 2 DAWs can run in perfect sync (like REWIRE) but maintain all their functionality?
Cubase and Ableton specifically in my case.

Is it even possible?

Cheers
Gaz 

Virus-free. www.avast.com

On Thu, Feb 1, 2018 at 12:38 AM, Ralf Mattes <[hidden email]> wrote:

Am Mittwoch, 31. Januar 2018 18:11 CET, Robert Bielik <[hidden email]> schrieb:

> Solved! It seems to be a systemd setting!!

Oh dear! Here I have a reply mail sitting open on my desktop for quite a while since I wasn't shure
whether suggesting to look into systemd would be too rude (o.k. - my chosen language in that mail
is rather harsh). I remembered vaguely that stupid (imho) idea to kill all user-stated processes at logout
(way cool if you start a long-running simulation/analysis job over the weekend only to come back on
monday to find your job killed by systemd).
An extra set of facepalms goes to the systemd team for implementing a stoopid "feature" and then
doing even this completely wrong :-)
Sytemd is _not_ cleaning IPC at all (with ipcclean or ipcrm), it's removing the file system handle.
Nothing more. Isn't anyone terrified by trusting core system functinality into the hands of the
programmer equivalent of "Happy Tree Friends"?

<note-to-self>must remove this crap!</note-to-self>

Glad you fond it,

 RalfD

>
> https://bbs.archlinux.org/viewtopic.php?pid=1487274#p1487274
>
> By setting RemoteIPC=No in /etc/system.d/logind.conf it all seems to work now!
>
> Regards
> /Robert
>
> > -----Original Message-----
> > From: Robert Bielik
> > Sent: den 31 januari 2018 17:58
> > To: Robert Bielik <[hidden email]>; [hidden email]
> > Subject: RE: [Jack-Devel] ?==?utf-8?q? Usage feasibility Q
> >
> > >
> > > Since the "original" size of /dev/shm was too small for jack2, I've added this
> > > to /etc/fstab (ripped from somewhere on the net):
> > >
> > > none    /dev/shm        tmpfs   defaults,size=128M      0       0
> >
> > Hmm... if I remove this line, the amount is ~464MB, so it was not needed
> > from the start. Doesn't change anything though...
> >
> > Regards
> > /Robert
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Usage feasibility Q

Robert Bielik
In reply to this post by Chris Caudle
> I think maybe the jack FAQ needs a section for headless use, it seems
> about twice a year some problem comes up and it takes a few days to work
> through all the variations of PAM and systemd caveats needed to get jack
> working on an appliance style device.

Which would be great. I've put together everything I needed to do in order to get it working: http://forum.audioinjector.net/viewtopic.php?f=5&t=2727&start=30#p5749

That link *should* be publicly accessible.

Regards
/Robert

_______________________________________________
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: ?= Usage feasibility

Chris Caudle
In reply to this post by Gaz Mellen
On Wed, January 31, 2018 6:07 pm, [hidden email] wrote:
> Does anyone know of someone who has a setup where 2 DAWs can run in
> perfect sync (like REWIRE) but maintain all their functionality?

Can you explain a little more what you mean?  You can keep sample rate
sync using jack, if you also want to keep transport sync then you would
need jack aware applications that support the jack transport API.  Ardour
and Mixbus do, Qtractor, not sure if there are others.  May depend on if
you really mean DAW or if you mean a MIDI sequencer and a DAW, there are a
few sequencers which can be synchronized to jack.

> Cubase and Ableton specifically in my case.

Which OS platform are  you using?  Jack is multi-platform, but was
primarily developed and maintained on linux.  There are Windows and Mac OS
ports, but a lot fewer people are experienced in getting jack working on
those platforms.

Cubase and Ableton I assume could be Windows or Mac OS, neither of those
supports jack natively, so would either treat jack as an ASIO device on
Windows, or a CoreAudio device on Mac OS.  I don't believe either of those
audio API's has a concept of "transport" or musical sync, only digital
audio sync, so you could transfer audio between the applications, but not
position within a musical arrangement or even start and stop.

Jack also transports MIDI, so possibly you could kludge up a way to use
MIDI to synchronize between applications which support MIDI sync, but I'm
just speculating at this point, I don't actually know enough about the
Windows port to know whether that would actually work or not.

--
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: ?= Usage feasibility

Gaz Mellen
Hey Chris,
Thanks so much for your input.
I'm primarily on Windows, I think you have answered the question, 
which would explain why I haven't heard or seen anyone with a setup using Cubase and Ableton.

I've seen Bidule do some interesting routing but again not exactly what I am looking for.

If you ever see this setup working please think of me, as it is my dream setup.

Thanks again for your time much appreciated!

Cheers
Gaz

Virus-free. www.avast.com

On Thu, Feb 1, 2018 at 10:02 AM, Chris Caudle <[hidden email]> wrote:
On Wed, January 31, 2018 6:07 pm, [hidden email] wrote:
> Does anyone know of someone who has a setup where 2 DAWs can run in
> perfect sync (like REWIRE) but maintain all their functionality?

Can you explain a little more what you mean?  You can keep sample rate
sync using jack, if you also want to keep transport sync then you would
need jack aware applications that support the jack transport API.  Ardour
and Mixbus do, Qtractor, not sure if there are others.  May depend on if
you really mean DAW or if you mean a MIDI sequencer and a DAW, there are a
few sequencers which can be synchronized to jack.

> Cubase and Ableton specifically in my case.

Which OS platform are  you using?  Jack is multi-platform, but was
primarily developed and maintained on linux.  There are Windows and Mac OS
ports, but a lot fewer people are experienced in getting jack working on
those platforms.

Cubase and Ableton I assume could be Windows or Mac OS, neither of those
supports jack natively, so would either treat jack as an ASIO device on
Windows, or a CoreAudio device on Mac OS.  I don't believe either of those
audio API's has a concept of "transport" or musical sync, only digital
audio sync, so you could transfer audio between the applications, but not
position within a musical arrangement or even start and stop.

Jack also transports MIDI, so possibly you could kludge up a way to use
MIDI to synchronize between applications which support MIDI sync, but I'm
just speculating at this point, I don't actually know enough about the
Windows port to know whether that would actually work or not.

--
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: ?= Usage feasibility

Kjetil Matheussen-2
In reply to this post by Chris Caudle


On Thu, Feb 1, 2018 at 4:02 AM, Chris Caudle <[hidden email]> wrote:
On Wed, January 31, 2018 6:07 pm, [hidden email] wrote:
> Does anyone know of someone who has a setup where 2 DAWs can run in
> perfect sync (like REWIRE) but maintain all their functionality?

Can you explain a little more what you mean?  You can keep sample rate
sync using jack, if you also want to keep transport sync then you would
need jack aware applications that support the jack transport API.  Ardour
and Mixbus do, Qtractor, not sure if there are others.  May depend on if
you really mean DAW or if you mean a MIDI sequencer and a DAW, there are a
few sequencers which can be synchronized to jack.


Radium, Ardour, and BitWig (I think) are the three DAWs on Windows that support Jack Transport, as far as I know.
And probably Mixbus.



> Cubase and Ableton specifically in my case.

Which OS platform are  you using?  Jack is multi-platform, but was
primarily developed and maintained on linux.  There are Windows and Mac OS
ports, but a lot fewer people are experienced in getting jack working on
those platforms.


I've been using jack on windows since around 2007. Haven't noticed any problems.
MacOS should be fine too.


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