Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #235253 > unrolled thread

audacity on Buster - qui est 'input?'

Back to article view | Back to linux.debian.user

Contents

  audacity on Buster - qui est 'input?' Bob Bernstein <poobah@ruptured-duck.com> - 2021-05-17 09:40 +0200
    Re: audacity on Buster - qui est 'input?' didier gaumet <didier.gaumet@gmail.com> - 2021-05-17 10:20 +0200
      Re: audacity on Buster - qui est 'input?' Bob Bernstein <poobah@ruptured-duck.com> - 2021-05-17 13:50 +0200
        Re: audacity on Buster - qui est 'input?' Greg Wooledge <greg@wooledge.org> - 2021-05-17 14:20 +0200
          Re: audacity on Buster - qui est 'input?' Andrei POPESCU <andreimpopescu@gmail.com> - 2021-05-17 14:40 +0200
        Re: audacity on Buster - qui est 'input?' didier gaumet <didier.gaumet@gmail.com> - 2021-05-17 15:00 +0200

#235253 — audacity on Buster - qui est 'input?'

Buster amd64:
$ uname -a
Linux debian.localdomain 4.19.0-14-amd64 #1 SMP Debian 
4.19.171-2 (2021-01-30) x86_64 GNU/Linux

$ dpkg -l |grep audacity
ii  audacity                                     2.2.2-1+b1 
amd64        fast, cross-platform audio editor
ii  audacity-data                                2.2.2-1 
all          fast, cross-platform audio editor (data)

On audacity's main screen the input device is set at ALSA with 
no other choices available.

If I hit Generate->Tone I can record and play back said tone.

But if I turn on a favorite internet radio station ("Your 
Classical") the signal does not find it's way into audacity, 
although I can listen to my machine's headphone jack with great 
pleasure.

This regardless of whether I select an input of 'default', 
'sysdefault', or any of the other half dozen or choices I tested 
but alas did not make a note of.

Question: given this hardware and underlying linux, what do 
others find works as 'input' for audacity?

Thank you.


-- 
RSB

[toc] | [next] | [standalone]

#235257

Hello,

This chapter of the on-line Audacity doc could be of interest to you:
https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_linux.html

[toc] | [prev] | [next] | [standalone]

#235263

On Mon, 17 May 2021, didier gaumet wrote:

> https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_linux.html

Much of the focus of the above is setting PulseAudio to launch 
as a system-wide service, for all users, but it goes on to say 
that if you make that choice, rather than launching it on a 
per-user basis, that you are "on your own."

I can take a hint. It seems to me I have to place the statement

pulseaudio --daemonize

in some user file or other but nowhere can I find in that doc 
(coulda missed it; I'm an old guy) a suggestion as to what file 
to use. I'm thinking what's wrong with just putting that into my 
.xsession file?

At some point, being an impulsive sonofagun, and a life-long 
subscriber to "don't read the manual; wing that sucker," I will 
try .xsession.

Comments, absent outright opprobrium, are welcome.

-- 
"No matter how big the problem is, you can always run away from it."
                             Dom Irrera

[toc] | [prev] | [next] | [standalone]

#235264

On Mon, May 17, 2021 at 07:45:34AM -0400, Bob Bernstein wrote:
> I can take a hint. It seems to me I have to place the statement
> 
> pulseaudio --daemonize
> 
> in some user file or other but nowhere can I find in that doc (coulda missed
> it; I'm an old guy) a suggestion as to what file to use. I'm thinking what's
> wrong with just putting that into my .xsession file?

I assumed this at first, too.  It seems right, doesn't it?  Sure.

But it doesn't work.  Pulseaudio is supposed to start *itself* automatically
upon demand.  It's supposed to "just work", and you're not supposed to
have to do anything to make it work.

When I tried putting a pulseaudio start-up command in my .xsession file,
I had problems.  Every single time -- and I mean 100% of the time, literally
*every* single time -- that I started an X session, I was left with a
nonresponsive pulseaudio daemon.  But if I stopped and restarted the
pulseaudio daemon, then it would work fine.

So, every time I started X, I had to manually stop pulseaudio, and
then manually restart it.

Eventually I figured out that the solution was *not* to start pulseaudio
myself.  Just let it autostart itself on demand.

For some reason, this works, but starting it myself does not work.

I have no idea why.  But there you go.  That's the answer, apparently.

[toc] | [prev] | [next] | [standalone]

#235270

[Multipart message — attachments visible in raw view] — view raw

On Lu, 17 mai 21, 08:16:39, Greg Wooledge wrote:
> On Mon, May 17, 2021 at 07:45:34AM -0400, Bob Bernstein wrote:
> > I can take a hint. It seems to me I have to place the statement
> > 
> > pulseaudio --daemonize
> > 
> > in some user file or other but nowhere can I find in that doc (coulda missed
> > it; I'm an old guy) a suggestion as to what file to use. I'm thinking what's
> > wrong with just putting that into my .xsession file?
> 
> I assumed this at first, too.  It seems right, doesn't it?  Sure.
> 
> But it doesn't work.  Pulseaudio is supposed to start *itself* automatically
> upon demand.  It's supposed to "just work", and you're not supposed to
> have to do anything to make it work.
> 
> When I tried putting a pulseaudio start-up command in my .xsession file,
> I had problems.  Every single time -- and I mean 100% of the time, literally
> *every* single time -- that I started an X session, I was left with a
> nonresponsive pulseaudio daemon.  But if I stopped and restarted the
> pulseaudio daemon, then it would work fine.
> 
> So, every time I started X, I had to manually stop pulseaudio, and
> then manually restart it.
> 
> Eventually I figured out that the solution was *not* to start pulseaudio
> myself.  Just let it autostart itself on demand.
> 
> For some reason, this works, but starting it myself does not work.
> 
> I have no idea why.  But there you go.  That's the answer, apparently.
 
As far as I can tell pulseaudio ships with .socket user unit that is 
activated by default, so your "manually" started pulseaudio instance 
might conflict with that.

This should be easy to test with

    systemctl --user stop pulseaudio.socket
    pulseaudio --daemonize

If that works and you prefer it you can just 'mask' the .socket unit to 
prevent it from starting[1].

On the other hand you might achieve the desired outcome simply be 
enabling the pulseaudio.service unit as it shouldn't conflict with the 
the .socket unit.

    systemctl --user enable --now pulseaudio.service


[1] because it's shipped enabled at system level a simple 'disable' 
won't work.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#235272

Le 17/05/2021 à 13:45, Bob Bernstein a écrit :
[...]
> Much of the focus of the above is setting PulseAudio to launch as a 
> system-wide service, for all users,
[...]
> pulseaudio --daemonize

It's not my impression. I agree with the reply of Greg Wooledge: to me, 
Pulseaudio is automatically started on a per_user basis,

didier@hp-notebook14:~$ systemctl --user | grep -i pulse
pulseaudio.service 
                  loaded active running   Sound Service 

pulseaudio.socket 
                  loaded active running   Sound System

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web