8 Jul
2017
8 Jul
'17
11:11 a.m.
I'm trying to run a script in my Odroid-U3 which launches Jack and Pd,
but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
I've tried launching it with cron (user's odroid cron, not root), by
appending the following line at the end:
@reboot sleep 30 ; sh /home/odroid/scripts/launch_jack_pd.sh
I've also tried launching it with rc.local, by placing the following
line before 'exit 0':
sudo -c '/home/odroid/scripts/launch_jack_pd.sh' - odroid &
None of them seem to work. Pd runs, but Jack doesn't. The script is
callable manually and works as expected. The Odroid runs lubunty 14.04.2
LTS, and Jack is jackdmp 1.9.10
Any tips?
8 Jul
8 Jul
11:22 a.m.
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000
Hi,
run the command from command line, perhaps you get something like
"ALSA: cannot set channel count to 2 for capture"
and/or
"ALSA: cannot set channel count to 4 for playback"
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sat Jul 8 18:22:39 CEST 2017
11:41 a.m.
On 07/08/2017 07:22 PM, Ralf Mardorf wrote:
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
I'm able to run
the command from the command line and Jack runs fine.
The thing is it won't run on boot. Actually, when booting up, after I
realize that Pd is running but Jack isn't (no sound is coming out, plus
the DSP can't go on in Pd, there's an LED for visual feedback that
doesn't go on), I SSH to the Odroid, and typing "top" sometimes shows
jack the first time, consuming quite some CPU (like 67 or even higher),
and then Jack disappears. Trying to kill Jack with "killall jackd" gives
me that there's no process found.
I read some threads about it and saw something about /etc/init.d/jackd
and /etc/default/jackd which were not in my system.
In this thread
http://linux-audio.4202.n7.nabble.com/autostarting-jackd-at-bootup-with-Ubu…
there are two links to these scripts, but putting them there (and making
/etc/init.d/jackd executable) didn't do the trick.
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000
Hi,
run the command from command line, perhaps you get something like
"ALSA: cannot set channel count to 2 for capture"
and/or
"ALSA: cannot set channel count to 4 for playback"
12:06 p.m.
On Sat, 8 Jul 2017 19:41:17 +0300, alex wrote:
I SSH to the Odroid, and typing "top"
sometimes shows
jack the first time, consuming quite some CPU (like 67 or even
higher), and then Jack disappears. Trying to kill Jack with "killall
jackd" gives me that there's no process found.
I read some threads about it and saw something about /etc/init.d/jackd
and /etc/default/jackd which were not in my system.
Hi,
just a shot into the dark. Are you using a hybrid systemd distro?
ls -l /?bin/init /lib/systemd/system-generators/systemd-sysv-generator
Why don't you write a log file?
date; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000
>>/tmp/jackd.log 2>&1 &
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sat Jul 8 19:06:16 CEST 2017
12:08 p.m.
On Sat, 8 Jul 2017 19:06:19 +0200, Ralf Mardorf wrote:
date; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1
-i2 -o4 -p512
-r48000 >>/tmp/jackd.log 2>&1 &
Oops, it should read
date >>/tmp/jackd.log; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1 -i2 -o4
-p512 -r48000 >>/tmp/jackd.log 2>&1 &
12:19 p.m.
You ensure that the device always is hw:1, by
/etc/modprobe.d/alsa-base.conf
options snd slots=,snd_driver_name
?
Why not using
hw:card_name
?
1:04 p.m.
On 07/08/2017 08:19 PM, Ralf Mardorf wrote:
You ensure that the device always is hw:1, by
/etc/modprobe.d/alsa-base.conf
options snd slots=,snd_driver_name
?
Why not using
hw:card_name
?
______________________________________________
Yes, It's a setup inside an
enclosure that I never touch, and the sound
card I'm using is always attached to the Odroid.
2:26 p.m.
On Sat, 8 Jul 2017 21:04:29 +0300, alex wrote:
Yes, It's a setup inside an enclosure that I never
touch, and the
sound card I'm using is always attached to the Odroid.
Hi,
that doesn't ensure that it's always hw:1. OTOH if you run the script
from command line and it works, then the device obviously is hw:1.
On Sat, 8 Jul 2017 21:04:03 +0300, alex wrote:
Well, I just tried to redirect jack's stdout and
stderr as you
suggested to /tmp/jackd.log, but it doesn't happen. I created the
following script called 'launch_jack.sh':
date >>/tmp/jackd.log; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1
-i2 -o4 -p512 -r48000 >>/tmp/jackd.log 2>&1 &
Do you get a log file, if you run the script from command line?
What distro are you using?
What init system are you using?
[rocketmouse@archlinux ~]$ cat /etc/modprobe.d/alsa-base.conf
# ALSA module ordering
options snd slots=snd_hdspm,snd_ice1712,snd_ice1712
[rocketmouse@archlinux ~]$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: HDSPMx579bcc [RME AIO_579bcc], device 0: RME AIO [RME AIO]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: EWX2496 [TerraTec EWX24/96], device 0: ICE1712 multi [ICE1712 multi]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 4: USB [Scarlett 18i20 USB], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
[rocketmouse@archlinux ~]$ grep PRETTY /etc/os-release
PRETTY_NAME="Arch Linux"
[rocketmouse@archlinux ~]$ pacman -Q jack2
jack2 1.9.10.r263.gf3a6b3e4-1
[rocketmouse@archlinux ~]$ jackd --version
jackdmp version 1.9.11-RC1 tmpdir /dev/shm protocol 8
[rocketmouse@archlinux ~]$ ls -l /?bin/init
/lib/systemd/system-generators/systemd-sysv-generator
ls: cannot access '/lib/systemd/system-generators/systemd-sysv-generator': No such
file or directory
lrwxrwxrwx 1 root root 22 Jul 6 15:27 /sbin/init -> ../lib/systemd/systemd
[rocketmouse@archlinux ~]$ rm /tmp/jackd.log
rm: cannot remove '/tmp/jackd.log': No such file or directory
[rocketmouse@archlinux ~]$ cat /tmp/foo.sh
#!/bin/bash
date >>/tmp/jackd.log; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1 -i2 -o4 -p512
-r48000 >>/tmp/jackd.log 2>&1 &
exit
[rocketmouse@archlinux ~]$ /tmp/foo.sh
jackd: no process found
[rocketmouse@archlinux ~]$ cat /tmp/jackd.log
Sat Jul 8 21:22:52 CEST 2017
no message buffer overruns
no message buffer overruns
no message buffer overruns
jackdmp 1.9.11-RC1
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:1|hw:1|512|2|48000|2|4|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: cannot set channel count to 2 for capture
ALSA: cannot configure capture channel
Released audio card Audio1
audio_reservation_finish
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
[rocketmouse@archlinux ~]$
Regards,
Ralf
12:30 p.m.
On Sat, 8 Jul 2017 19:11:31 +0300
alex <adrcki(a)gmail.com> wrote:
I'm trying to run a script in my Odroid-U3 which
launches Jack and
Pd, but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
Maybe you need a sleep to make sure that jack is really running before
you start pd?
--
Joakim
12:37 p.m.
On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
On Sat, 8 Jul 2017 19:11:31 +0300
alex <adrcki(a)gmail.com> wrote:
But the script runs fine when launched manually. It's just that
jack
won't run on boot.
I'm trying to run a script in my Odroid-U3
which launches Jack and
Pd, but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
Maybe you need a sleep to make
sure that jack is really running before
you start pd?
12:54 p.m.
On Sat, 8 Jul 2017 20:37:51 +0300, alex wrote:
On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
If you start jackd at boot, you start it for the very first time. If
you start jackd after that from command line, it's already in the cache
and might launch faster. I don't think it's the culprit, but it
explains that running software for the first time does take longer, than
starting it for the second time.
Maybe you need a sleep to make sure that jack is
really running
before you start pd?
But the script runs fine when launched manually. It's
just that jack
won't run on boot.
12:56 p.m.
On 07/08/2017 08:54 PM, Ralf Mardorf wrote:
On Sat, 8 Jul 2017 20:37:51 +0300, alex wrote:
So do you recommend to add a delay after launching
jack and before
launching pd?
On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
If you start jackd at boot, you start it for the very first
time. If
you start jackd after that from command line, it's already in the cache
and might launch faster. I don't think it's the culprit, but it
explains that running software for the first time does take longer, than
starting it for the second time. Maybe you need a sleep to make sure that jack is
really running
before you start pd?
But the script runs fine when launched manually. It's
just that jack
won't run on boot.
12:59 p.m.
On Sat, 8 Jul 2017 20:56:02 +0300, alex wrote:
On 07/08/2017 08:54 PM, Ralf Mardorf wrote:
It doesn't harm.
But instead of continuing guessing, it's much more important to
redirect jackd's stdout und stderr to a log file, as explained by
precious replies.
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sat Jul 8 19:59:34 CEST 2017
On Sat, 8 Jul 2017 20:37:51 +0300, alex wrote:
So do you recommend to add a delay after
launching jack and before
launching pd? On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
If you start jackd at boot, you start it for the very
first time. If
you start jackd after that from command line, it's already in the
cache and might launch faster. I don't think it's the culprit, but it
explains that running software for the first time does take longer,
than starting it for the second time. Maybe you need a sleep to make sure that jack is
really running
before you start pd?
But the script runs fine when launched manually. It's
just that jack
won't run on boot.
1:01 p.m.
On Sat, 8 Jul 2017 19:59:36 +0200, Ralf Mardorf wrote:
On Sat, 8 Jul 2017 20:56:02 +0300, alex wrote:
^^^^^^^^
A funny typo :D. "previous"
On 07/08/2017 08:54 PM, Ralf Mardorf wrote:
It doesn't harm.
But instead of continuing guessing, it's much more important to
redirect jackd's stdout und stderr to a log file, as explained by
precious replies. On Sat, 8 Jul 2017 20:37:51 +0300, alex wrote:
So do you recommend to add a
delay after launching jack and before
launching pd? On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
> Maybe you need a sleep to make sure that jack is really running
> before you start pd?
But the script runs fine when launched manually. It's just that
jack won't run on boot.
If you start jackd at boot, you start it for the
very first time. If
you start jackd after that from command line, it's already in the
cache and might launch faster. I don't think it's the culprit, but
it explains that running software for the first time does take
longer, than starting it for the second time.
1:04 p.m.
On 07/08/2017 08:59 PM, Ralf Mardorf wrote:
On Sat, 8 Jul 2017 20:56:02 +0300, alex wrote:
Well, I just tried to redirect jack's stdout and stderr as
you suggested
to /tmp/jackd.log, but it doesn't happen. I created the following script
called 'launch_jack.sh':
date >>/tmp/jackd.log; killall -9 jackd; sleep 5; jackd -dalsa -dhw:1
-i2 -o4 -p512 -r48000 >>/tmp/jackd.log 2>&1 &
And then changed the rc.local to call this script, but there's no
jackd.log file. Again, if I run the script manually from the terminal,
the file is created and the following is being written in it:
sáb ene 1 11:35:26 ACDT 2000
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:1|hw:1|512|2|48000|2|4|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
But only when started manually..
On 07/08/2017 08:54 PM, Ralf Mardorf wrote:
It doesn't harm.
But instead of continuing guessing, it's much more important to
redirect jackd's stdout und stderr to a log file, as explained by
precious replies. On Sat, 8 Jul 2017 20:37:51 +0300, alex wrote:
So do you recommend to add a delay after
launching jack and before
launching pd? On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
> Maybe you need a sleep to make sure that jack is really running
> before you start pd?
But the script runs fine when launched manually. It's just that jack
won't run on boot.
If you start jackd at boot, you start it for the very first
time. If
you start jackd after that from command line, it's already in the
cache and might launch faster. I don't think it's the culprit, but it
explains that running software for the first time does take longer,
than starting it for the second time.
2:57 p.m.
On Sat, 8 Jul 2017 20:37:51 +0300
alex <adrcki(a)gmail.com> wrote:
On 07/08/2017 08:30 PM, Joakim Hernberg wrote:
Missed that.
Jack has to be run as a user daemon, though there a promiscuous mode
that would allow it to be started by any user (or root) and still be
available for use by any other user.
--
Joakim
On Sat, 8 Jul 2017 19:11:31 +0300
alex <adrcki(a)gmail.com> wrote:
But the script runs fine when launched manually. It's
just that jack
won't run on boot. I'm trying to run a script in my Odroid-U3
which launches Jack and
Pd, but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
Maybe you need a sleep to
make sure that jack is really running
before you start pd? 
4:48 p.m.
On 07/08/2017 09:57 PM, Joakim Hernberg wrote:
Jack has to be run as a user daemon, though there a
promiscuous mode
that would allow it to be started by any user (or root) and still be
available for use by any other user.
but both jack and pd are started from the same script, so they belong to
the same user/session/seat.
what you say is true if you have 2 init-scripts, one for jack the other
for Pd; but this doesn't seem to be the case here.
fgmsar
IOhannes
12:39 p.m.
On Sat, 8 Jul 2017 19:30:17 +0200, Joakim Hernberg wrote:
Maybe you need a sleep to make sure that jack is really
running before
you start pd?
I suspect it wouldn't explain:
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
Pd runs, but Jack doesn't.
On Sat, 8 Jul 2017 19:41:17 +0300, alex wrote:
I SSH to the Odroid, and typing "top"
sometimes shows
jack the first time, consuming quite some CPU (like 67 or even
higher), and then Jack disappears.
I would redirect jackd's stdout und stderr to a log file.
I guess "jackd... &>>log.file" does the same as my "jackd...
>>log.file 2>&1" does ;).
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sat Jul 8 19:39:19 CEST 2017
1:20 p.m.
On 07/08/2017 07:30 PM, Joakim Hernberg wrote:
On Sat, 8 Jul 2017 19:11:31 +0300
alex <adrcki(a)gmail.com> wrote:
OT here, but there's `jack_wait` (comes with jackd) to wait for JACK to
become available (better than "sleep").
2c,
robin
I'm trying to run a script in my Odroid-U3
which launches Jack and
Pd, but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
Maybe you need a sleep to make sure that jack is really running before
you start pd?
2:29 p.m.
New subject: [Jack-Devel] ?==?utf-8?q? Jack won't start on boot
Am Samstag, 08. Juli 2017 20:20 CEST, Robin Gareus <robin(a)gareus.org> schrieb:
OT here, but there's `jack_wait` (comes with jackd) to wait for JACK to
become available (better than "sleep").
Not OT at all. I was just starting to write a grumpy reply myself.
Just a few questions/suggestions:
- when you test your script do you run it as the same user as during bootup?
- init scripts do run in a very restricted environment. Test your script with a
stripped environment:
/usr/bin/env -i /path/to/launch_jack_pd.sh
Cheers, Ralf Mattes
2c,
robin
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
2:54 p.m.
New subject: [Jack-Devel] ?==?utf-8?q? Jack won't start on boot
On Sat, 08 Jul 2017 21:29:53 +0200, Ralf Mattes wrote:
- init scripts do run in a very restricted
environment. Test your
script with a stripped environment:
Let alone that some distros are hybrids, actually using systemd (units),
but providing systemd-sysv-generator.
This is asking for trouble!
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sat Jul 8 21:54:16 CEST 2017
9 Jul
9 Jul
6:28 a.m.
On 07/08/2017 09:20 PM, Robin Gareus wrote:
On 07/08/2017 07:30 PM, Joakim Hernberg wrote:
I get similar behavior, works
fine manually with 'jack_wait -w' but on
boot jack_wait waits for ever as jack never starts.
On Sat, 8 Jul 2017 19:11:31 +0300
alex <adrcki(a)gmail.com> wrote:
OT here, but there's `jack_wait` (comes with jackd) to wait for JACK to
become available (better than "sleep"). I'm trying to run a script in my Odroid-U3
which launches Jack and
Pd, but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
Maybe you need a sleep to make
sure that jack is really running before
you start pd?
3:13 p.m.
On 07/08/2017 11:05 PM, Ralf Mardorf wrote:
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
Don't know, the only two ways I
know of launching stuff on boot is
either via cron and rc.local. I'm no Linux guru so there's probably
stuff I'm ignorant of.
I've tried launching it with cron
With
cron and an init script? There still could be a race condition,
even if you added "killall -9".
_______________________________________________ 
10:03 p.m.
Am 08.07.2017 um 22:13 schrieb alex:
On 07/08/2017 11:05 PM, Ralf Mardorf wrote:
I would go for a systemd service to do that, given that you distro is
systemd based.
[Unit]
Description=JACK startup on boot.
After=sound.target
[Service]
User=USERNAME
Environment="XDG_RUNTIME_DIR=/run/user/USERID"
ExecStart=path/to/your/script
[Install]
WantedBy=multi-user.target
were USERNAME needs to be replaced with your username, and USERID with
your ID, get it with
id -u $(logname)
then save the file into
/usr/lib/systemd/system/jack.service
and run
systemctl enable jack.service
systemctl daemon-reload
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
Don't know, the only two ways
I know of launching stuff on boot is
either via cron and rc.local. I'm no Linux guru so there's probably
stuff I'm ignorant of. I've tried launching it with cron
With
cron and an init script? There still could be a race condition,
even if you added "killall -9".
_______________________________________________
9 Jul
9 Jul
4:48 a.m.
On Sun, 9 Jul 2017 05:03:22 +0200, Hermann Meyer wrote:
I would go for a systemd service to do that, given that
you distro is
systemd based.
Hi,
since we nicer know what distro the OP does use, nor what init process,
the OP should consider to run the commands I already mentioned.
ls -l /?bin/init
shows what is used.
ls -l /lib/systemd/system-generators/systemd-sysv-generator
might show if it's a hybrid, systemd + init scripts.
cat /etc/*{release,version,issue}
should show what distro is used and maybe what release. There are more
advanced commands, depending on the distro. On Ubuntu e.g. running
lsb_release -irc
could be useful.
Regards,
Ral
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 11:48:16 CEST 2017
4:54 a.m.
On Sun, 9 Jul 2017 11:48:17 +0200, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 05:03:22 +0200, Hermann Meyer
wrote:
^^^^^ neither
I would go for a systemd service to do that, given
that you distro is
systemd based.
Hi,
since we nicer know what distro the OP does use, nor what init process, the OP should consider to run the commands I already
mentioned.
ls -l /?bin/init
shows what is used.
ls -l /lib/systemd/system-generators/systemd-sysv-generator
might show if it's a hybrid, systemd + init scripts.
cat /etc/*{release,version,issue}
should show what distro is used and maybe what release. There are more
advanced commands, depending on the distro. On Ubuntu e.g. running
lsb_release -irc
could be useful.
Regards,
Ral
^^^ Ralf
If I should have made typos when typing the commands, Google as well as
previous posts should help ;)
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 11:53:57 CEST 2017
5:55 a.m.
On 07/09/2017 12:48 PM, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 05:03:22 +0200, Hermann Meyer
wrote:
I did mention the
OS in the OP
I would go for a systemd service to do that,
given that you distro is
systemd based.
Hi,
since we nicer know what distro the OP does use, nor what init process,
the OP should consider to run the commands I already mentioned. ls -l /?bin/init
This gives the following:
-rwxr-xr-x 1 root root 194844 jul 18 2014 /sbin/init
shows what is used.
ls -l /lib/systemd/system-generators/systemd-sysv-generator
This gives the
following:
ls: cannot access /lib/systemd/system-generators/systemd-sysv-generator:
No such file or directory
might show if it's a hybrid, systemd + init
scripts.
cat /etc/*{release,version,issue}
This threw a lot of information that's too
much to post here. Should I
run something more specific? Should I replace "release", "version",
"issue" with something?
should show what distro is used and maybe what
release. There are more
advanced commands, depending on the distro. On Ubuntu e.g. running
lsb_release -irc
Distributor ID: Ubuntu
Release: 14.04
Codename: trusty
I know it's an old distribution of Ubuntu, but the Odroid-U3 is now
obsolete and I'm not sure I'd like to upgrade to a newer version since
almost everything works now in my project. Jack not launching on boot is
the last issue I have to solve.
6:10 a.m.
On Sun, 9 Jul 2017 13:55:26 +0300, alex wrote:
Distributor ID: Ubuntu
Release: 14.04
Codename: trusty
This is a very good information :).
See https://wiki.ubuntu.com/SystemdForUpstartUsers .
You are _not_ using systemd, or a hybrid. You are using upstart, IOW
init scripts.
So _unfortunately_ you could ignore Hermann's suggestion to use a
systemd unit.
Again, troubleshooting should be done by redirecting messages to a log
file + taking into account what Neil mentions, assuming you should try
with ALSA instead of jackd.
However, I don't understand why you do not get a log file :(.
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 13:09:59 CEST 2017
6:27 a.m.
On 07/09/2017 02:10 PM, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 13:55:26 +0300, alex wrote:
So, I should replace (not that I've tried already) Hermann's
suggestion
with the following:
description "Job that runs the foo daemon"
# start in normal runlevels when disks are mounted and networking is available
start on runlevel [2345]
# stop on shutdown/halt, single-user mode and reboot
stop on runlevel [016]
env statedir=/var/cache/foo
# create a directory needed by the daemon
pre-start exec mkdir -p "$statedir"
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir "$statedir"
Taken from the link you provided, right? This example is for a
/etc/init/foo.conf file. Should I create a /etc/init/jackd.conf file? If
so, I guess I should change some stuff, like the last two lines. But
what should I put there instead?
Distributor ID: Ubuntu
Release: 14.04
Codename: trusty
This is a very good information :).
See https://wiki.ubuntu.com/SystemdForUpstartUsers .
You are _not_ using systemd, or a hybrid. You are using upstart, IOW
init scripts.
So _unfortunately_ you could ignore Hermann's suggestion to use a
systemd unit.
Again, troubleshooting should be done by redirecting messages to a log
file + taking into account what Neil mentions, assuming you should try
with ALSA instead of jackd.
-rt is the default behavior in Pd, if I'm not
mistaken. Never-the-less I
tried to launch it with this flag and ALSA but I still get dropouts.
However, I don't understand why you do not get a log file :(.
I'll try
again. I tried to add 'jack_wait -w' to my script, and again
running manually works fine, but on boot jack_wait waits for ever and
jack never starts.
6:38 a.m.
On 07/09/2017 02:26 PM, alex wrote:
On 07/09/2017 02:10 PM, Ralf Mardorf wrote:
jack_wait -w actually helped with creating a log file.
Here's the output:
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
Failed to connect to session bus for device reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
Audio device hw:1 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Even if I change hw:1 to hw:USB I get the same with:
Audio device hw:USB cannot be acquired...
Is there a chance that jack starts before the system sees the USB sound
card? Should I put a 'sleep 10' before launching jack in the script?
On Sun, 9 Jul 2017 13:55:26 +0300, alex wrote:
So, I should replace (not that I've tried already) Hermann's
suggestion with the following:
description "Job that runs the foo daemon"
# start in normal runlevels when disks are mounted and networking is available
start on runlevel [2345]
# stop on shutdown/halt, single-user mode and reboot
stop on runlevel [016]
env statedir=/var/cache/foo
# create a directory needed by the daemon
pre-start exec mkdir -p "$statedir"
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir "$statedir"
Taken from the link you provided, right? This example is for a
/etc/init/foo.conf file. Should I create a /etc/init/jackd.conf file?
If so, I guess I should change some stuff, like the last two lines.
But what should I put there instead?
Distributor ID: Ubuntu
Release: 14.04
Codename: trusty
This is a very good information :).
Seehttps://wiki.ubuntu.com/SystemdForUpstartUsers .
You are _not_ using systemd, or a hybrid. You are using upstart, IOW
init scripts.
So _unfortunately_ you could ignore Hermann's suggestion to use a
systemd unit. Again, troubleshooting should be done by
redirecting messages to a log
file + taking into account what Neil mentions, assuming you should try
with ALSA instead of jackd.
-rt is the default behavior in Pd, if I'm not
mistaken. Never-the-less
I tried to launch it with this flag and ALSA but I still get dropouts.
However, I don't understand why you do not
get a log file :(.
I'll try again. I tried to add 'jack_wait -w' to my
script, and again
running manually works fine, but on boot jack_wait waits for ever and
jack never starts. 
9:06 a.m.
On Sun, July 9, 2017 13:37, alex wrote:
The following seems to happen: when you start jackd manually, you already
have a graphical environment providing $DISPLAY which is again used by
dbus.
When you start jackd during boot, it will fail if there is no graphical
environment started yet.
Many distros have stock jackd that expects dbus which again is relatively
tightly bound to the desktop.
You can try these things:
-compile jackd without dbus support (if you don't need it for your app)
-start jackd with a startup mechanism that's run by your graphical
environment (after it's ready and $DISPLAY is set)
Hope that helps,
Thomas
I'll try
again. I tried to add 'jack_wait -w' to my script, and again
running manually works fine, but on boot jack_wait waits for ever and
jack never starts.
jack_wait -w actually helped with creating a log file.
Here's the output:
jackdmp 1.9.10 Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you
are welcome to redistribute it under certain conditions; see the file
COPYING for details
JACK server starting in realtime mode with priority 10
Failed to connect to session bus for device reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
Audio device hw:1 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
9:15 a.m.
On Sun, 9 Jul 2017 16:04:10 +0200, Thomas Brand wrote:
On Sun, July 9, 2017 13:37, alex wrote:
That's the culprit :). Forget my _wrong_ assumption about something else
grabbing the device.
Regards,
Ralf
Failed to connect to session bus for device
reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
The following seems to happen: when
you start jackd manually, you
already have a graphical environment providing $DISPLAY which is again
used by dbus.
When you start jackd during boot, it will fail if there is no graphical
environment started yet.
9:20 a.m.
On Sun, July 9, 2017 16:15, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 16:04:10 +0200, Thomas Brand
wrote:
ok :)
On Sun, July 9, 2017 13:37, alex wrote:
That's the culprit :). Forget my _wrong_ assumption about something else
grabbing the device.
Failed to connect to session bus for device
reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
The following seems to happen: when
you start jackd manually, you
already have a graphical environment providing $DISPLAY which is again
used by dbus. When you start jackd during boot, it will fail if there is
no graphical environment started yet.
9:23 a.m.
On Sun, 9 Jul 2017 16:18:50 +0200, Thomas Brand wrote:
On Sun, July 9, 2017 16:15, Ralf Mardorf wrote:
:D
My apologies, I didn't read carefully enough. Without doubts you
mentioned the culprit :).
On Sun, 9 Jul 2017 16:04:10 +0200, Thomas Brand
wrote:
ok :) On Sun, July 9, 2017 13:37, alex wrote:
That's the culprit :). Forget my _wrong_ assumption about something
else grabbing the device.
Failed to connect to session bus for device
reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
The following seems to happen: when
you start jackd manually, you
already have a graphical environment providing $DISPLAY which is
again used by dbus. When you start jackd during boot, it will fail
if there is no graphical environment started yet.
9:31 a.m.
On Sun, July 9, 2017 16:23, Ralf Mardorf wrote:
ok :)
:D
My apologies, I didn't read carefully enough. Without doubts you
mentioned the culprit :).
well the log did haha.. and that one came in late.
> Failed to
connect to session bus for device reservation Unable to
> autolaunch a dbus-daemon without a $DISPLAY$
The following seems to happen: when you start jackd manually, you
already have a graphical environment providing $DISPLAY which is
again used by dbus. When you start jackd during boot, it will fail
if there is no graphical environment started yet.
That's the culprit :). Forget my _wrong_ assumption about something
else grabbing the device.
9:22 a.m.
On 07/09/2017 05:04 PM, Thomas Brand wrote:
On Sun, July 9, 2017 13:37, alex wrote:
The following seems to happen: when you start jackd manually, you already
have a graphical environment providing $DISPLAY which is again used by
dbus.
When you start jackd during boot, it will fail if there is no graphical
environment started yet.
Many distros have stock jackd that expects dbus which again is relatively
tightly bound to the desktop.
You can try these things:
-compile jackd without dbus support (if you don't need it for your app)
-start jackd with a startup mechanism that's run by your graphical
environment (after it's ready and $DISPLAY is set)
Indeed that seems like a
reason. I'm SSHing into to Odroid with -X so I
can launch Pd with its GUI, so I tried to SSH without -X and jack
wouldn't start, but then SSHing back with -X made jack start.
I'd rather not compile something since it took me quite some time to
find an image for the Odroid with which I could get descent sound. Since
now the sound is coming out nice, I'd rather keep the software the way
it is. That being said, I'd rather go for your second suggestion.
Can you post an example of how I should start jack with a startup
mechanism that's run by my graphical environment? I'm not really
following there...
I'll
try again. I tried to add 'jack_wait -w' to my script, and again
running manually works fine, but on boot jack_wait waits for ever and
jack never starts.
jack_wait -w actually helped with creating a log file.
Here's the output:
jackdmp 1.9.10 Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you
are welcome to redistribute it under certain conditions; see the file
COPYING for details
JACK server starting in realtime mode with priority 10
Failed to connect to session bus for device reservation Unable to
autolaunch a dbus-daemon without a $DISPLAY$
Audio device hw:1 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
9:28 a.m.
On Sun, July 9, 2017 16:21, alex wrote:
> On 07/09/2017 05:04 PM, Thomas Brand
wrote:
>> On Sun, July 9, 2017 13:37, alex
wrote:
> >>>> I'll try again. I tried to
add 'jack_wait -w' to my script, and
>>>> again running manually works fine, but on boot jack_wait waits for
>>>> ever and jack never starts.
>>> jack_wait -w actually helped with creating a log file. Here's the
>>> output:
>> >> >>
>>> jackdmp 1.9.10 Copyright 2001-2005 Paul Davis and others. Copyright
>>> 2004-2013 Grame.
>>> jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and
>>> you are welcome to redistribute it under certain conditions; see the
>>> file COPYING for details
>>> JACK server starting in realtime mode with priority 10
>>> Failed to connect to session bus for device reservation Unable to
>>> autolaunch a dbus-daemon without a $DISPLAY$
>> >>> Audio
device hw:1 cannot be acquired...
>>> Cannot initialize driver
>>> JackServer::Open failed with -1
>>> Failed to open server
>> >> >> The following seems to happen: when you
start jackd manually, you
>> already have a graphical environment providing $DISPLAY which is again
>> used by dbus. When you start jackd during boot, it will fail if there is
>> no graphical environment started yet.
> >> Many distros have stock jackd that
expects dbus which again is
>> relatively tightly bound to the desktop.
> >> You can try these things:
>> -compile jackd without dbus support (if you don't need it for your app)
>> -start jackd with a startup mechanism that's run by your graphical
>> environment (after it's ready and $DISPLAY is set)
> Indeed that seems like a reason. I'm SSHing into to Odroid with -X so I
> can launch Pd with its GUI, so I tried to SSH without -X and jack wouldn't
> start, but then SSHing back with -X made jack start.
> I'd rather not compile something since
it took me quite some time to
> find an image for the Odroid with which I could get descent sound. Since
> now the sound is coming out nice, I'd rather keep the software the way it
> is. That being said, I'd rather go for your second suggestion. Can you
> post an example of how I should start jack with a startup mechanism that's
> run by my graphical environment? I'm not really following there...
Ah.. maybe this is a headless system so you can't do that.
Compiling jack is straight forward. install build-essential, clone jackd
github repo and you're almost there.
IIRC there are hacks that pretend a dbus env for jack, somebody has to
chime in.
9:34 a.m.
On 9 July 2017 at 22:21, alex <adrcki(a)gmail.com> wrote:
Indeed that seems like a reason. I'm SSHing into to Odroid with -X so I
can launch Pd with its GUI, so I tried to SSH without -X and jack wouldn't
start, but then SSHing back with -X made jack start.
Can you post an example of how I should start jack with a startup
mechanism that's run by my graphical environment? I'm not really following
there...
Having the graphical environment start jackd assumes that there is a
graphical environment running on the Odroid, which I don't believe is the
case here? Using -X with ssh forwards X11 connection attempts on the Odroid
to the X server on your local machine, but since dbus afaik isn't network
transparent[1] the DISPLAY you end up with via ssh -X will I think not be
useful for the dbus side of jack. So you can probably get away with setting
DISPLAY to something arbitrary in your init script, like:
DISPLAY=:0 jackd -dalsa ...
[1] https://news.ycombinator.com/item?id=5130928
-sqweek
9:53 a.m.
On 07/09/2017 05:34 PM, sqweek wrote:
On 9 July 2017 at 22:21, alex <adrcki(a)gmail.com
<mailto:adrcki@gmail.com>> wrote:
Indeed that seems like a reason. I'm SSHing into to Odroid with -X
so I can launch Pd with its GUI, so I tried to SSH without -X and
jack wouldn't start, but then SSHing back with -X made jack start.
Can you post an example of how I should start jack with a startup
mechanism that's run by my graphical environment? I'm not really
following there...
Having the graphical environment start jackd assumes that there is a
graphical environment running on the Odroid, which I don't believe is
the case here? Using -X with ssh forwards X11 connection attempts on
the Odroid to the X server on your local machine, but since dbus afaik
isn't network transparent[1] the DISPLAY you end up with via ssh -X
will I think not be useful for the dbus side of jack. So you can
probably get away with setting DISPLAY to something arbitrary in your
init script, like:
DISPLAY=:0 jackd -dalsa ...
That did it, kind of... Jack is starting and Pd too,
but I get no sound.
The DSP does go on (there's an LED on the synth I've built that goes on
when Pd's DSP is on) but I can't hear anything.
Now though, I can SSH into the Odroid without -X and the script
launching jack and Pd works and sounds works fine.
This is jack's log:
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:USB|hw:USB|512|2|48000|2|4|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
JackEngine::XRun: client = pure_data_0 was not finished, state = Triggered
Jack main caught signal 15
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = pure_data_0 was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Released audio card Audio1
audio_reservation_finish
But this is the log when the script is run manually (and sound works
properly):
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2013 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:USB|hw:USB|512|2|48000|2|4|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 512 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
Jack main caught signal 15
JackEngine::XRun: client = pure_data_0 was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Released audio card Audio1
audio_reservation_finish
So, what could the issue be now?
10:14 a.m.
On Sun, 9 Jul 2017 17:53:15 +0300, alex wrote:
So, what could the issue be now?
Hi,
the log and the command line output are more or less equal [1]!
Hardware limitations and/or not optimal real-time tuning might cause
this issue.
For testing purpose try
-n 3 -p 1024
this would lead to
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 3 periods
What's the output of
uname -r
and
/etc/init.d/rtirq status
Note, there are more options than using a "good" kernel and Rui's rtirq
script, but those are starting points to optimize real-time usage.
Regards,
Ralf
[1] To avoid another mistake I saved both outputs and run
diff /tmp/Unsaved\ Document\ 1 /tmp/Unsaved\ Document\ 2
as well as
meld /tmp/Unsaved\ Document\ 1 /tmp/Unsaved\ Document\ 2
;)
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 17:14:49 CEST 2017
11:27 a.m.
On 07/09/2017 06:14 PM, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 17:53:15 +0300, alex wrote:
That
didn't do the trick, unfortunately
So, what could the issue be now?
Hi,
the log and the command line output are more or less equal [1]!
Hardware limitations and/or not optimal real-time tuning might cause
this issue.
For testing purpose try
-n 3 -p 1024
this would lead to
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 3 periods
What's the output of
uname -r
3.8.13.30
and
/etc/init.d/rtirq status
-bash: /etc/init.d/rtirq: No such file or directory
Note, there are more options than using a "good" kernel and Rui's rtirq
script, but those are starting points to optimize real-time usage.
So the issue is
that I don't have a real-time kernel?
12:09 p.m.
On Sun, 9 Jul 2017 19:27:16 +0300, alex wrote:
On 07/09/2017 06:14 PM, Ralf Mardorf wrote:
No. Even the so called Ubuntu lowlatency kernel is not patched with the
real-time patch. Even a vanilla kernel comes with some kind of
real-time capability. How good it is depends on the configuration.
First of all add "threadirqs" to your bootloader's options and then run
sudo apt-get update
sudo apt-get install rtirq-init
after that edit "RTIRQ_NAME_LIST=" of the file /etc/default/rtirq .
I don't know what to add to that file's list for your architecture. For
example "rtc" doesn't make sense on most modern machines, but I don't
have a clue what makes sense for your architecture.
However, maybe don't edit anything or better just add
usb
at first of that list and reboot and after
that run
/etc/init.d/rtirq status
and post the output to the mailing list.
This becomes a little bit OT for this mailing list. you might get
better help on https://lists.linuxaudio.org/listinfo/linux-audio-user .
Compiling and building the packages for a rt patched kernel is easy to
do for Ubuntu, but you might not need a rt patched kernel at all.
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 19:09:48 CEST 2017
uname -r
3.8.13.30
/etc/init.d/rtirq status
-bash:
/etc/init.d/rtirq: No such file or directory
So the issue is that I don't have a real-time kernel?
12:23 p.m.
The content of
/etc/security/limits.conf
or
/etc/security/limits.d/audio.conf
are important, too.
The output of the command
id
shows, if the user is added to the real-time/audio group that should be
mentioned by /etc/security/limits.conf
or /etc/security/limits.d/audio.conf . When installing jack on Ubuntu,
a dialoge should have ask you to set up limits... as well as adding
the user to the real-time/audio group.
1:12 p.m.
On 07/09/2017 08:23 PM, Ralf Mardorf wrote:
The content of
/etc/security/limits.conf
or
/etc/security/limits.d/audio.conf
are important, too.
I've set the following to both:
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -19
The output of the command
id
shows, if the user is added to the real-time/audio group that should be
mentioned by /etc/security/limits.conf
or /etc/security/limits.d/audio.conf . When installing jack on Ubuntu,
a dialoge should have ask you to set up limits... as well as adding
the user to the real-time/audio group.
The user 'odroid' is in the audio
group and I've answered yes when
installing jack about the real-time priority.
Tomorrow I'll try installing rtirq.
2:14 p.m.
On Sun, 9 Jul 2017 21:12:53 +0300, alex wrote:
On 07/09/2017 08:23 PM, Ralf Mardorf wrote:
Perfect. Btw. the nice value is null and void, you could remove it or
keep it, it doesn't affect rt priority. It's recommended to use
"rtprio 99" - http://jackaudio.org/faq/linux_rt_config.html .
"99" is what I actually use. IIRC some people go below "99" to avoid
an
unresponsive GUI. I never experienced such an issue, even with oldish
machines. FWIW you only need one of those files, but you could keep
both files, it doesn't matter.
The content of
/etc/security/limits.conf
or
/etc/security/limits.d/audio.conf
are important, too.
I've set the following to both:
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -19 The user 'odroid' is in the audio group and
I've answered yes when
installing jack about the real-time priority.
Perfect.
10:31 a.m.
On Sun, 9 Jul 2017 17:14:50 +0200, Ralf Mardorf wrote:
What's the output of
uname -r
Hi,
https://packages.ubuntu.com/trusty-updates/linux-lowlatency is only
available for amd64 and i386 architecture, so ensure that you boot a
default kernel with "threadirqs".
I don't now how to edit the config for the config of GRUB2, but for
syslinux the one and only config would look similar to
[rocketmouse@archlinux ~]$ grep "LABEL Threadirqs" -A4
/boot/syslinux/syslinux.cfg
LABEL Threadirqs
MENU LABEL Arch Linux ^threadirqs
LINUX ../vmlinuz-linux
APPEND root=LABEL=archlinux ro threadirqs
INITRD ../initramfs-linux.img
Install https://packages.ubuntu.com/trusty/rtirq-init and edit
/etc/default/rtirq .
Reboot and run
/etc/init.d/rtirq status
this might show if additional tuning might help, e.g. unbinding devices.
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 17:31:50 CEST 2017
19 Jul
19 Jul
4:14 p.m.
On 07/09/2017 05:34 PM, sqweek wrote:
On 9 July 2017 at 22:21, alex <adrcki(a)gmail.com
<mailto:adrcki@gmail.com>> wrote:
Indeed that seems like a reason. I'm SSHing into to Odroid with -X
so I can launch Pd with its GUI, so I tried to SSH without -X and
jack wouldn't start, but then SSHing back with -X made jack start.
Can you post an example of how I should start jack with a startup
mechanism that's run by my graphical environment? I'm not really
following there...
Having the graphical environment start jackd assumes that there is a
graphical environment running on the Odroid, which I don't believe is
the case here? Using -X with ssh forwards X11 connection attempts on
the Odroid to the X server on your local machine, but since dbus afaik
isn't network transparent[1] the DISPLAY you end up with via ssh -X
will I think not be useful for the dbus side of jack. So you can
probably get away with setting DISPLAY to something arbitrary in your
init script, like:
DISPLAY=:0 jackd -dalsa ...
Eventually that did it! At first I replied to this
email saying that it
partially worked since jack was starting but no sound was coming out.
Eventually the latter happened due to some (probably) bug in Pd which I
"solved" with a work around.
So now I can safely say that adding "DISPLAY=:0 before calling jackd did
the trick and now I do get sound on boot.
Thanks everyone for your suggestions!
5:08 p.m.
Yuri <yuri(a)rawbw.com> writes:
On 07/19/2017 14:14, alex wrote:
One Dbus to rule them all, one Dbus to find them,
one Dbus to bring them all and on the DISPLAY bind them...
It defines your console.
--
David Kastrup
So now I can safely say that adding "DISPLAY=:0 before calling jackd
did the trick and now I do get sound on boot.
Why and how does jackd depend on DISPLAY? 
5:27 p.m.
On 07/19/2017 15:08, David Kastrup wrote:
Only python code depends on DBus in jack1, not C code. The "jackit"
package doesn't depend on DBus.
So I can't figure out how does DBus factor in the jackd boot process.
Yuri
Why and how
does jackd depend on DISPLAY?
One Dbus to rule them all, one Dbus to find them,
one Dbus to bring them all and on the DISPLAY bind them...
It defines your console. 
20 Jul
20 Jul
4:33 a.m.
On Wed, Jul 19, 2017 at 03:27:25PM -0700, Yuri wrote:
On 07/19/2017 15:08, David Kastrup wrote:
Only python code depends on DBus in jack1, not C code. The "jackit"
package doesn't depend on DBus.
So I can't figure out how does DBus factor in the jackd boot process.
The situation is different with jack2, which has a --dbus compile
option.
John
Why and
how does jackd depend on DISPLAY?
One Dbus to rule them all, one Dbus to find
them,
one Dbus to bring them all and on the DISPLAY bind them...
It defines your console.
4:23 a.m.
On Wed, Jul 19, 2017 at 03:00:27PM -0700, Yuri wrote:
On 07/19/2017 14:14, alex wrote:
Because it was compiled with dbus support. That makes jackd refuse
to start unless it thinks X is running. I recompile jack2 on Debian
without dbus for this reason.
John
So now I can safely say that adding "DISPLAY=:0 before calling jackd
did the trick and now I do get sound on boot.
Why and how does jackd depend on DISPLAY?
4:39 a.m.
On 07/20/2017 01:44, John Rigg wrote:
Because it was compiled with dbus support. That makes
jackd refuse
to start unless it thinks X is running. I recompile jack2 on Debian
without dbus for this reason.
This appears to be a wrong behavior that jackd ever requires a DISPLAY
variable, because sound should have nothing to do with X.
Yuri
4:57 a.m.
On 20 July 2017 at 17:39, Yuri <yuri(a)rawbw.com> wrote:
On 07/20/2017 01:44, John Rigg wrote:
I'm not going to disagree with you, but your distaste is directed at the
wrong list. Jack2 uses dbus to cooperate with pulseaudio so that they can
co-exist on the same machine. And while I'd personally rather run jack by
itself, pulseaudio unfortunately seems to be a requirement for eg.
bluetooth audio on linux at present.
-Rowan
Because it was compiled with dbus support. That
makes jackd refuse
to start unless it thinks X is running. I recompile jack2 on Debian
without dbus for this reason.
This appears to be a wrong behavior that jackd ever requires a DISPLAY
variable, because sound should have nothing to do with X.
5:05 a.m.
New subject: [Jack-Devel] ?==?utf-8?q? Jack won't start on boot
Am Donnerstag, 20. Juli 2017 11:39 CEST, Yuri <yuri(a)rawbw.com> schrieb:
This appears to be a wrong behavior that jackd ever requires a DISPLAY
variable, because sound should have nothing to do with X.
It's not Jack that requires the display, but D-Bus (and that seems fair, given that
d-bus stands for _Desktop Bus_).
So, iff you choose to run a jackd that was explicitly comiled with desktop session
support,
the assumption that it need a running desktop session doesn't seem wrong.
Cheers, Ralf Mattes
Yuri
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
5:35 a.m.
On 07/20/2017 03:05, Ralf Mattes wrote:
It's not Jack that requires the display, but D-Bus
(and that seems fair, given that
d-bus stands for_Desktop Bus_).
So, iff you choose to run a jackd that was explicitly comiled with desktop session
support,
the assumption that it need a running desktop session doesn't seem wrong.
Cheers, Ralf Mattes
The logic "(that) D-Bus (requires the display) ... seems fair, given
that d-bus stands for _Desktop Bus_" is actually incorrect. The only
connection of DBus to X is that DBus for some reason can auto-launch X.
Only bin/dbus-launch is linked to libX11.so. DBus is the desktop bus in
the name only. DBus is an IPC mechanism, and essentially has nothing to
do with X. In fact, removing --with-x in DBus makes it disconnect from
X. The fact that any DBus-linked program requires X indicates some
problem. This should never happen.
Yuri
6:16 a.m.
On 20 July 2017 at 18:35, Yuri <yuri(a)rawbw.com> wrote:
The logic "(that) D-Bus (requires the display) ... seems fair, given that
d-bus stands for _Desktop Bus_" is actually incorrect. The only connection
of DBus to X is that DBus for some reason can auto-launch X. Only
bin/dbus-launch is linked to libX11.so. DBus is the desktop bus in the name
only. DBus is an IPC mechanism, and essentially has nothing to do with X.
In fact, removing --with-x in DBus makes it disconnect from X. The fact
that any DBus-linked program requires X indicates some problem. This should
never happen.
DBus relies on a known address for the clients to communicate on. If an
address is not specified it will automatically derive a unix socket based
on the DISPLAY environment variable (if set). Presumably setting
DBUS_SESSION_BUS_ADDRESS explicitly would also suffice as a workaround,
it's just more typing and more arcane.
ie. Jack doesn't require X under any circumstances, but if compiled with
dbus support it _does_ require a valid session bus to connect to and the
simplest way to arrange for that to happen is to set DISPLAY.
-Rowan
8:37 a.m.
On Thu, July 20, 2017 13:16, sqweek wrote:
On 20 July 2017 at 18:35, Yuri <yuri(a)rawbw.com>
wrote:
I wondered if jackd could proceed as if there was no DBus support compiled
in, once it fails to connect to it. That would silently solve such issues.
(?)
Greetings
Thomas
The logic "(that) D-Bus (requires the display) ... seems fair, given
that d-bus stands for _Desktop Bus_" is actually incorrect. The only
connection of DBus to X is that DBus for some reason can auto-launch X.
Only
bin/dbus-launch is linked to libX11.so. DBus is the desktop bus in the
name only. DBus is an IPC mechanism, and essentially has nothing to do
with X. In fact, removing --with-x in DBus makes it disconnect from X.
The fact
that any DBus-linked program requires X indicates some problem. This
should never happen.
DBus relies on a known address for the clients to communicate on. If an
address is not specified it will automatically derive a unix socket based
on the DISPLAY environment variable (if set). Presumably setting
DBUS_SESSION_BUS_ADDRESS explicitly would also suffice as a workaround,
it's just more typing and more arcane.
ie. Jack doesn't require X under any circumstances, but if compiled with
dbus support it _does_ require a valid session bus to connect to and the
simplest way to arrange for that to happen is to set DISPLAY.
8 Jul
8 Jul
4:49 p.m.
On 07/08/2017 06:11 PM, alex wrote:
I'm trying to run a script in my Odroid-U3 which
launches Jack and Pd,
but Jack doesn't start.
do you actually *need* jack (any functionality that it provides which
cannot be satisfied by Pd's ALSA backend), or is it just because you are
used to it?
gmrdsa
IOhannes
9 Jul
9 Jul
4:59 a.m.
On 07/09/2017 12:49 AM, IOhannes m zmölnig wrote:
On 07/08/2017 06:11 PM, alex wrote:
I do need it cause I can't get audio without dropouts neither with
ALSA
nor with PortAudio on my Odroid.
I'm trying to run a script in my Odroid-U3
which launches Jack and Pd,
but Jack doesn't start.
do you actually *need* jack (any functionality that it
provides which
cannot be satisfied by Pd's ALSA backend), or is it just because you are
used to it?
5:18 a.m.
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
See
https://en.wikipedia.org/wiki/ODROID#Operating_systems
we can't know what distro you are using, since there are several
distros available. Apart from this, even while Arch Linux is
mentioned, it at least can't be an official Arch Linux, since "Currently
we have official packages optimized for the i686 and x86-64
architectures", see https://www.archlinux.org/ , so we need much more
information about your operating system and at least about the used init
process.
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 12:18:09 CEST 2017
6:50 a.m.
On 07/09/2017 12:18 PM, Ralf Mardorf wrote:
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
i think you missed a bit in the original post:
On 07/08/2017 06:11 PM, alex wrote:
I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
See
https://en.wikipedia.org/wiki/ODROID#Operating_systems
we can't know what distro you are using, since there are several
distros available. The Odroid runs lubunty 14.04.2 LTS, and Jack is
jackdmp 1.9.10
while i don't know much about the odroid distributions, i guess this
pretty much narrows down the actually used distribution.
gmsard
IOhannes
9:08 a.m.
On Sun, 9 Jul 2017 13:49:55 +0200, IOhannes m zmölnig wrote:
On 07/08/2017 06:11 PM, alex wrote:
Hi,
oops, indeed. I wasn't the only one missing the last sentence,
before the final question.
However, now we are aware that it's an upstart distribution.
On Sun, 9 Jul 2017 14:26:55 +0300, alex wrote:
The Odroid runs lubunty 14.04.2 LTS, and Jack is
jackdmp 1.9.10
while i don't know much about the odroid distributions, i guess this
pretty much narrows down the actually used distribution. So, I should replace (not that I've tried already)
Hermann's
suggestion with the following [snip]
Google is your friend ;). I don't know what you need to consider, when
using upstart. I guess the scripts should be equal to other init
scripts. Anyway, yes, you need to ignore Hermann's suggestion.
On Sun, 9 Jul 2017 14:37:56 +0300, alex wrote:
Audio device hw:1 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Even if I change hw:1 to hw:USB I get the same with:
Audio device hw:USB cannot be acquired...
Since you don't get an "Invalid value for card", something else might
grab the audio interface. Maybe pulseaudio?
https://packages.ubuntu.com/trusty-updates/amd64/pulseaudio/filelist
shows /etc/init.d/pulseaudio .
See
https://help.ubuntu.com/community/UbuntuBootupHowto#Directories_and_Configs
+ Ubuntu's so called user-friendly policy to automatically start
everything that could be started for an installed package, seems to
point to this or another service already grabbing the audio interface.
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 16:08:42 CEST 2017
9:20 a.m.
On Sun, July 9, 2017 16:08, Ralf Mardorf wrote:
Maybe everything is a follow-up issue of jack not being able to use dbus
(for device reservation)?
"Failed to connect to session bus for device reservation"
Greetings
Thomas
Even if I
change hw:1 to hw:USB I get the same with:
Audio device hw:USB cannot be acquired...
Since you don't get an "Invalid value for card", something else might
grab the audio interface. Maybe pulseaudio?
5:22 a.m.
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
Too funny, since you actually try to use the ALSA backend ;).
On Sat, 8 Jul 2017 19:11:31 +0300, alex wrote:
I'm trying to run a script in my Odroid-U3 which
launches Jack and Pd,
but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
^^^^
^^^^
*?*
5:28 a.m.
On Sun, Jul 9, 2017 at 11:22 AM Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
wrote:
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
Not that funny if you assume that ALSA isn't being started with real-time
privileges. Isn't there a Pd option (-rt) for that?
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
Too funny, since you actually try to use the ALSA backend ;).
5:39 a.m.
On Sun, 09 Jul 2017 10:28:40 +0000, Neil C Smith wrote:
On Sun, Jul 9, 2017 at 11:22 AM Ralf Mardorf
<ralf.mardorf(a)alice-dsl.net> wrote:
My apologies,
regarding https://puredata.info/docs/faq/commandline there is
such an option. See "other flags":
"-rt or -realtime -- use real-time priority
-nrt -- don't use real-time priority"
Regards,
Ralf
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
Not that funny if you assume that ALSA isn't being started with
real-time
privileges. Isn't there a Pd option (-rt) for that? I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
Too funny, since you actually try to use the ALSA backend ;).
5:41 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Sun, 9 Jul 2017 12:58:55 +0300, alex wrote:
Shrug. Jackd does not offer backends of its own. Its point is that it
puts the real-time critical part of audio processing into a separate
process so that it can be better prioritized (as well as developed and
optimized) than something running in the same process and address space
as a large audio processing application.
So it's not really all that surprising that some backend works better
with jackd in the middle than using it directly. If it were, Jack would
be sort-of pointless compared to something like alsalib.
--
David Kastrup
I do need it cause I can't get audio without
dropouts neither with
ALSA nor with PortAudio on my Odroid.
Too funny, since you actually try to use the ALSA backend ;).
5:47 a.m.
On Sun, 09 Jul 2017 12:41:44 +0200, David Kastrup wrote:
So it's not really all that surprising that some
backend works better
with jackd in the middle than using it directly. If it were, Jack
would be sort-of pointless compared to something like alsalib.
Actually Ardour gives a choice to use ALSA or jackd, while my RME card
only could be used choosing jackd, since choosing ALSA doesn't work at
all.
[rocketmouse@archlinux ~]$ arecord -l | grep RME
card 0: HDSPMx579bcc [RME AIO_579bcc], device 0: RME AIO [RME AIO]
However, jackd would _not_ be pointless.
The question
On Sat, 8 Jul 2017 23:49:41 +0200, IOhannes m zmölnig wrote:
do you actually *need* jack
is a valid question, even if ALSA should work without any issues, since
jackd allows to connect individual apps when not using an all in one
approach.
Regards,
Ralf
--
Vote for apulse!
echo $(w3m https://aur.archlinux.org/packages/apulse |grep 'Votes: ')
Votes: 84 Updated: Sun Jul 9 12:47:42 CEST 2017
6:43 a.m.
On Sun, Jul 9, 2017 at 12:41 PM, David Kastrup <dak(a)gnu.org> wrote:
with jackd in the middle than using it directly. If
it were, Jack would
be sort-of pointless compared to something like alsalib.
Even though you wrote "sort-of", it still needs a comment.
Alsalib is very low-level, and shouldn't really be used by any
type of software except for libraries like jack, pulseaudio,
portaudio, etc. that provides more high level audio APIs.
I would think there's been billions (or at least thousands)
of bugs in the linux audio world because people have
have misunderstood the point of alsalib, and used it
directly in their application instead of a higher level library.
8:10 p.m.
At the risk of asking an obvious question, have you tried increasing PD's
audio delay setting when using the ALSA backend? Maybe a number close to
your JACK buffer size might help eliminate the dropouts.
On Sun, Jul 9, 2017 at 6:58 PM, alex <adrcki(a)gmail.com> wrote:
On 07/09/2017 12:49 AM, IOhannes m zmölnig wrote:
On 07/08/2017 06:11 PM, alex wrote:
I do need it cause I can't get audio without dropouts neither with ALSA
nor with PortAudio on my Odroid.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
I'm trying to run a script in my Odroid-U3
which launches Jack and Pd,
but Jack doesn't start.
do you actually *need* jack (any functionality that it provides which
cannot be satisfied by Pd's ALSA backend), or is it just because you are
used to it?
12:36 p.m.
On 07/08/2017 06:11 PM, alex wrote:
I'm trying to run a script in my Odroid-U3 which
launches Jack and Pd,
but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
I've tried launching it with cron (user's odroid cron, not root), by
appending the following line at the end:
@reboot sleep 30 ; sh /home/odroid/scripts/launch_jack_pd.sh
I've also tried launching it with rc.local, by placing the following
line before 'exit 0':
sudo -c '/home/odroid/scripts/launch_jack_pd.sh' - odroid &
None of them seem to work. Pd runs, but Jack doesn't. The script is
callable manually and works as expected. The Odroid runs lubunty 14.04.2
LTS, and Jack is jackdmp 1.9.10
Any tips?
Try uncommenting the following line in /etc/pam.d/su:
# session required pam_limits.so
Best,
Jeremy
1:05 p.m.
On 07/09/2017 08:36 PM, Jeremy Jongepier wrote:
On 07/08/2017 06:11 PM, alex wrote:
That's uncommented...
I'm trying to run a script in my Odroid-U3
which launches Jack and Pd,
but Jack doesn't start.
This is my script, called 'launch_jack_pd.sh':
#!/bin/bash
jackd -dalsa -dhw:1 -i2 -o4 -p512 -r48000 &
pd -jack -inchannels 2 -outchannels 4 -nogui -open
I've tried launching it with cron (user's odroid cron, not root), by
appending the following line at the end:
@reboot sleep 30 ; sh /home/odroid/scripts/launch_jack_pd.sh
I've also tried launching it with rc.local, by placing the following
line before 'exit 0':
sudo -c '/home/odroid/scripts/launch_jack_pd.sh' - odroid &
None of them seem to work. Pd runs, but Jack doesn't. The script is
callable manually and works as expected. The Odroid runs lubunty 14.04.2
LTS, and Jack is jackdmp 1.9.10
Any tips?
Try uncommenting the following line in /etc/pam.d/su:
# session required pam_limits.so
2711
days inactive
2723
days old
jackaudio@lists.linuxaudio.org
74 comments
16 participants
participants (16)
-
alex -
David Kastrup -
Hermann Meyer -
IOhannes m zmölnig -
Jeremy Jongepier -
Joakim Hernberg -
John Rigg -
Kjetil Matheussen -
michael noble -
Neil C Smith -
Ralf Mardorf -
Ralf Mattes -
Robin Gareus -
sqweek -
Thomas Brand -
Yuri