Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?

[Len Ovens]

On Sat, 3 Jul 2021, John Murphy wrote:


On Wed, 30 Jun 2021 16:11:47 -0700 M. Edward (Ed) Borasky wrote:


The biggest issue with Pipewire IMHO is that it does not support
Ubuntu 18.04 LTS. That will be a big obstacle to growth until 18.04 is
no longer supported, which is still about two years away. I don't know
what's involved in doing a backport, but I for one would use Pipewire
if it was working on 18.04.


I've just seen a response from SOURAV DAS posted on 11 May to:

https://ubuntuhandbook.org/index.php/2021/05/install-latest-pipewire-ppa-ubuntu-20-04/

Saying "Hi, the PPA maintainer here. Now added supports for Ubuntu
18.04 also."

Linux Mint 20.1 (Ubuntu 20.04) here, so haven't tested it.


18.04 is of interest because... after that Ubuntu drops 32 bit ... 
everything they could get away with. It is for this reason I have switched 
at least one of my computers to debian. Not of interest to linux audio in 
general, except this 32bit laptop did save a recording session when the 
"recording machine" with win 10 showed up without the proper driver for 
the interface which worked just fine on this linux box because the 
interface was usb 2.0.


However, to be more inline with the topic: beware that if you wish to use 
pipewire on ubuntu, the above ppa is required because none of the releases 
keep up with this quickly changing software. Also, be aware that (last I 
heard) the ffado backend is not supported. The expectation is that the 
alsa drivers will just work. If the current kernel will actually load the 
snd- (mine does not right now), the performance is even worse 
than usb boxes. So for firewire, jack is still king and usb 2.0 audio can 
still not match most firewire devices despite their age. With a properly 
setup pipewire, pipewire should auto bridge to jackd... I have not 
achieved this yet but I have not had time really either. Getting a boat in 
the water so the family could spend last week "messing about with boats" 
has been more important ;)


--
Len Ovens
www.ovenwerks.net
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] updates

[Fons Adriaensen]

Hello all,

updates on 

zita-jacktools-1.5.2

   Fixed some bugs that made the class destructors segfault.

jconvolver-1.1.0
jmatconvol-0.4.2

   Added -T option to fconvolver and fmatconvol, truncates
   output file to input file size.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[John Murphy]

Many thanks for the input Wim. Sorry to distract you from the work.

My user id is indeed 1000 and $XDG_RUNTIME_DIR is /run/user/1000
where there is a pipewire-0 socket (0 bytes) and a pipewire-0.lock
of the same size.

I ran the line below from the command line first and it worked.
Tried it in the cronjob and it works there too!!

PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record /home/john/crontest.wav

The script I was using runs jack_record (for the 'duration').
I added a line like: export PIPEWIRE_RUNTIME_DIR=/run/user/1000
and changed the cronjob accordingly. That works too, so I am sorted.

Sincere thanks to all for the help. I'm still learning much.

John.


On Fri, 9 Jul 2021 14:25:03 +0200 Wim Taymans wrote:
> You need to make sure the cron script can find the local socket to
> talk to pipewire.
> 
> It searches for the socket named pipewire-0 in:
> 
> $PIPEWIRE_RUNTIME_DIR
> $XDG_RUNTIME_DIR
> $HOME
> ~/
> 
> I'm guessing that the cron script is running with a different user
> and/or does not have
> the same environment variables as the main pipewire daemon and thus
> looks in a different
> place and can't find a socket.
> 
> Normally the user running the daemon will set
> XDG_RUNTIME_DIR=/run/user/1000 and the
> socket will be named /run/user/1000/pipewire-0
> 
> Substitute 1000 for the user id.
> 
> Try this in the cron script:
> 
> PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record
> 
> An try again. I'm pretty sure it's a socket path thing. There is no
> dbus, systemd or device permissions
> involved. You need to check if the cronjob can find and has
> permissions to connect to the socket and
> that's it.
> 
> Wim
> 
> 
> 
> 
> 
> 
> On Wed, 7 Jul 2021 at 17:47, John Murphy  wrote:
> >
> > Could someone please do a simple test on any Pipewire installation
> > set up to use/replace Jack (or shed any light on this).
> >
> > If I run 'pw-record crontest.wav' it works fine, as expected.
> > If I run 'pw-cat 2> er.txt' ditto, of course.
> >
> > If I setup a user cronjob with 'crontab -e' to run the commands
> > (at the start of the next minute or so) the first does nothing,
> > while the second works.
> >
> > Cron writes to /var/log/syslog like:
> >
> > CRON[7694]: (john) CMD (pw-record crontest.wav)
> > rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
> >
> > (second line repeated)
> >
> > --
> > John (older than 95.6% of the population).
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > https://lists.linuxaudio.org/listinfo/linux-audio-dev  
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[Wim Taymans]

You need to make sure the cron script can find the local socket to
talk to pipewire.

It searches for the socket named pipewire-0 in:

$PIPEWIRE_RUNTIME_DIR
$XDG_RUNTIME_DIR
$HOME
~/

I'm guessing that the cron script is running with a different user
and/or does not have
the same environment variables as the main pipewire daemon and thus
looks in a different
place and can't find a socket.

Normally the user running the daemon will set
XDG_RUNTIME_DIR=/run/user/1000 and the
socket will be named /run/user/1000/pipewire-0

Substitute 1000 for the user id.

Try this in the cron script:

PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record

An try again. I'm pretty sure it's a socket path thing. There is no
dbus, systemd or device permissions
involved. You need to check if the cronjob can find and has
permissions to connect to the socket and
that's it.

Wim






On Wed, 7 Jul 2021 at 17:47, John Murphy  wrote:
>
> Could someone please do a simple test on any Pipewire installation
> set up to use/replace Jack (or shed any light on this).
>
> If I run 'pw-record crontest.wav' it works fine, as expected.
> If I run 'pw-cat 2> er.txt' ditto, of course.
>
> If I setup a user cronjob with 'crontab -e' to run the commands
> (at the start of the next minute or so) the first does nothing,
> while the second works.
>
> Cron writes to /var/log/syslog like:
>
> CRON[7694]: (john) CMD (pw-record crontest.wav)
> rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
>
> (second line repeated)
>
> --
> John (older than 95.6% of the population).
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[John Murphy]

On Fri, 9 Jul 2021 11:35:43 +0200 Dominique Michel wrote:
> Le Fri, 9 Jul 2021 09:52:18 +0100,
> John Murphy  a écrit :
> 
> > On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel wrote:  
> > > On linux, the audio devices can be acceded by only 1 user at a time.
> > > Which imply, instead of being root for everything audio related, I
> > > would login as an user member of the audio group and, instead of
> > > using cron, make a custom user script.
> > 
> > Thanks, but if Pipewire is going to prevent access to audio devices by
> > cronjobs, either accidentally or by design, then I'll be removing it.  
> 
> That issue have nothing to do with pipewire, but with how the
> kernel ALSA driver works. Which imply, instead of trying to workaround
> normal kernel operations and user/group permissions, you must work with
> them. It will be both much simpler and more reliable on the long run to
> use a joe user member of the audio group, and instead of messing with
> cron jobs which was never intended to be used to implement joe user
> tasks, just make a joe user (bash-python-...) script that will implement
> what you want to do.

I should have made clear from the start of this thread that I had been
running a script via user cron, to do the recording, which had worked
just fine (obviously not with pw-record) for months prior to installing
Pipewire. It's certainly possible I did something wrong, or that I did
something else around the same time to cause the problem. Which is why
I've asked if it works for others. No one seems to want to answer
definitively.

I was just using pw-record for testing. I couldn't actually use it in
my script as it doesn't have a -d (duration) option. 

-- 
Thanks again, John.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[Keith Edmunds]

> instead of messing with cron jobs which was never intended to be used to
> implement joe user tasks

Au contraire, that is exactly what cron is for.

I would agree that the /etc/crontab file should not be used for user
tasks, nor the /etc/cron.* directories that most distros support.

However, there is also the crontab(1) command which allows per-user
crontabs to be set up. The start of the man page even says, "crontab -
maintain crontab files for individual users".

So no, don't use the system cron files under /etc, but do use the crontab
commands to manage user jobs.
-- 
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:

Follow: https://www.facebook.com/KMBEngland
On Friday go to: https://www.mixcloud.com/live/KeithsMusicBox/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[Dominique Michel]

Le Fri, 9 Jul 2021 09:52:18 +0100,
John Murphy  a écrit :

> On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel wrote:
> > On linux, the audio devices can be acceded by only 1 user at a time.
> > Which imply, instead of being root for everything audio related, I
> > would login as an user member of the audio group and, instead of
> > using cron, make a custom user script.  
> 
> Thanks, but if Pipewire is going to prevent access to audio devices by
> cronjobs, either accidentally or by design, then I'll be removing it.

That issue have nothing to do with pipewire, but with how the
kernel ALSA driver works. Which imply, instead of trying to workaround
normal kernel operations and user/group permissions, you must work with
them. It will be both much simpler and more reliable on the long run to
use a joe user member of the audio group, and instead of messing with
cron jobs which was never intended to be used to implement joe user
tasks, just make a joe user (bash-python-...) script that will implement
what you want to do.
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[John Murphy]

On Thu, 8 Jul 2021 19:12:29 -0700 Fernando Lopez-Lezcano wrote:
> On 7/8/21 11:29 AM, John Murphy wrote:
> > 04 19 * * * root /usr/bin/pw-record /home/john/crontest.wav > 
> > /tmp/cronjob.txt 2>&1
> > and see the same error in the text file.  
> 
> Maybe running as root is actually not enough :-(
> 
> I don't know how to fix this but it is likely that this does not 
> establish a "session" (or "seat") and then dbus is not running and then 
> nothing that depends on it can work. Maybe running the cron job as a 
> normal user? I don't know how you can convince the system that you 
> really are allowed to do all this...

Identical error with the /etc/crontab entry run by user john. 

> < and if selinux is involved, maybe you can look at what is in the logs? 
> /var/log/secure, /var/log/messages, and hunt for denials or permission 
> problems? >

No selinux thank Dev ('getenforce' returns command not found).

I was running 'tail -f /var/log/syslog' (no /var/log/[messages|secure])
when I saw the CRON and rtkit-daemon messages in my opening post. Would
expect to have seen an entry there for any other problem at the time.

-- 
Thanks again, John.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[John Murphy]

On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel wrote:
> On linux, the audio devices can be acceded by only 1 user at a time.
> Which imply, instead of being root for everything audio related, I would
> login as an user member of the audio group and, instead of using cron,
> make a custom user script.

Thanks, but if Pipewire is going to prevent access to audio devices by
cronjobs, either accidentally or by design, then I'll be removing it.

-- 
John.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Simple Pipewire test request

[Dominique Michel]

Le Thu, 8 Jul 2021 19:12:29 -0700,
Fernando Lopez-Lezcano  a écrit :


> >> It could also be that running things from cron does not establish a
> >> "session" and then you do not have access permission to audio
> >> devices and such (and dbus, as suggested elsewhere in the thread).
> >>  
> > 
> > It's a long time since I've used root for anything, but I think it
> > would still have the required permissions to do anything. I begin to
> > wonder if this is by design, but I still don't know if it works for
> > anyone else.

On linux, the audio devices can be acceded by only 1 user at a time.
Which imply, instead of being root for everything audio related, I would
login as an user member of the audio group and, instead of using cron,
make a custom user script.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev