Jim Lesurf wrote:

Use alsamixer and press F4 to show the capture inputs. You should then be
able to experiment (as outlined on
http://www.audiomisc.co.uk/Linux/ALSA/ALSAforUsers.html
)
with which capture device you choose. If that doesn't work we can try
adding to the .asoundrc file. But I'm still wondering if the device
actually outputs audio in a standard pcm format. You should, however, be
able to get 'garbage' - i.e. non-zero streams of 'samples' - if that is the
case and you can select a format that copes.

I've just spent a couple of hours trying to get the sound output to work
on a Linux install on my laptop. The problem turned out to be the one
thing I never imagined it might be - the LFE output in the alsamixer was
muted! And this was for playing mono and stereo wav files. Insane!

In article , John
Legon
wrote:
Jim Lesurf wrote:

Use alsamixer and press F4 to show the capture inputs. You should then
be able to experiment (as outlined on
http://www.audiomisc.co.uk/Linux/ALSA/ALSAforUsers.html ) with which
capture device you choose. If that doesn't work we can try adding to
the .asoundrc file. But I'm still wondering if the device actually
outputs audio in a standard pcm format. You should, however, be able
to get 'garbage' - i.e. non-zero streams of 'samples' - if that is the
case and you can select a format that copes.

I've just spent a couple of hours trying to get the sound output to work
on a Linux install on my laptop. The problem turned out to be the one
thing I never imagined it might be - the LFE output in the alsamixer was
muted! And this was for playing mono and stereo wav files. Insane!

Afraid that looks like an example of how the developers these days tend to
make assumptions about how 'most users' will use their machine. Combined by
how the playing software was set up. And the distro.programs using Pulse or
some other sound 'layer' by default which tries to be too clever and take
control out of the hands of the mere user.

The assumptions tend to be things like 'surround sound' and 'mp3 files'
these days. Not plain and decent stereo LPCM.

Its generally curable with alsamixer or an .asoundrc file. But the user
then hits the problem of lack of clear documentation. Hence the pages I
wrote that deal with questions I've seen appear many times. FWIW the other
page I did at http://www.audiomisc.co.uk/Linux/ALS...reSilence.html
may also help for such.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf wrote:
In article , John
Legon
wrote:
I've just spent a couple of hours trying to get the sound output to work
on a Linux install on my laptop. The problem turned out to be the one
thing I never imagined it might be - the LFE output in the alsamixer was
muted! And this was for playing mono and stereo wav files. Insane!

Afraid that looks like an example of how the developers these days tend to
make assumptions about how 'most users' will use their machine. Combined by
how the playing software was set up. And the distro.programs using Pulse or
some other sound 'layer' by default which tries to be too clever and take
control out of the hands of the mere user.

The assumptions tend to be things like 'surround sound' and 'mp3 files'
these days. Not plain and decent stereo LPCM.

Well, whatever. The fact is that a fresh install on my laptop won't
play even Ubuntu's own start-up sound when the desktop appears after
booting because of some obscure and totally irrelevant setting in an
equally obscure audio mixer program that can only be accessed through a
terminal program...

In article , John
Legon
wrote:
Jim Lesurf wrote:

[snip]

Well, whatever. The fact is that a fresh install on my laptop won't
play even Ubuntu's own start-up sound when the desktop appears after
booting because of some obscure and totally irrelevant setting in an
equally obscure audio mixer program that can only be accessed through a
terminal program...

Well, the next fact is that it is then up to you if you want to try and
sort it out or not. :-)

Yes, I've had the same problem. The cure was to bypass Pulse audio and use
ALSA.

However, the reality is hardware and user preferences vary a lot. So the
install has to make some guesses or assumptions. I feel that additions like
Pulse are a PITA (and may be the cause in your case). Hence my preference
to simply use alsa. Magic-wand desktop GUI software tends to hide what you
end up needing. And IMHO the assumptions distro developers make about
audio seem daft to me. But I can't tell how typical I am of most users.
As a hi-fi fanatic I may be well out of the usual. That said, this seems
an insanely common problem which should be telling developers they are
making the wrong assumptions!

That said, problems like this can't always be avoided due to the sheer range
of detailed circumstances. Manufacturers can often dodge this by
pre-installing and matching hardware with settings, but that may *still*
provide a setup that doesn't do what a given user wants out-of-the-box.

Your machine may be 'playing' audio, but via an output you aren't actually
using. Or require a simple change like an unmute. Given the other things
you've done I'm surprised if you are terrified of a terminal. Your choice,
though. For getting output from internal hardware the fix is probably
simple, and outlined on the pages I wrote as work-throughs.

For something like the EZCap for capture I suspect the problem is harder
as I'm far from sure it identifies itself correctly over USB and then
provides standard LPCM format. Since I don't have one I'll have to defer
beyond that to those who have!


Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf wrote:
In article , John
Legon
wrote:
Jim Lesurf wrote:

[snip]

Well, whatever. The fact is that a fresh install on my laptop won't
play even Ubuntu's own start-up sound when the desktop appears after
booting because of some obscure and totally irrelevant setting in an
equally obscure audio mixer program that can only be accessed through a
terminal program...

Well, the next fact is that it is then up to you if you want to try and
sort it out or not. :-)

Yes, I've had the same problem. The cure was to bypass Pulse audio and use
ALSA.

However, the reality is hardware and user preferences vary a lot. So the
install has to make some guesses or assumptions. I feel that additions like
Pulse are a PITA (and may be the cause in your case). Hence my preference
to simply use alsa. Magic-wand desktop GUI software tends to hide what you
end up needing. And IMHO the assumptions distro developers make about
audio seem daft to me. But I can't tell how typical I am of most users.
As a hi-fi fanatic I may be well out of the usual. That said, this seems
an insanely common problem which should be telling developers they are
making the wrong assumptions!

A computer operating system worthy of the name shouldn't be making
assumptions, but should identify the hardware it is running on and
configure itself accordingly, presenting options to the user which are
relevant to the hardware.

That said, problems like this can't always be avoided due to the sheer range
of detailed circumstances. Manufacturers can often dodge this by
pre-installing and matching hardware with settings, but that may *still*
provide a setup that doesn't do what a given user wants out-of-the-box.

What happens with Windows, of course, is that the manufacturers supply
device drivers, which define valid options for the hardware in question.
But often it seems that those manufactures don't provide drivers for
linux, which is left floundering and dependent upon hacking to determine
what needs to be done.


Your machine may be 'playing' audio, but via an output you aren't actually
using. Or require a simple change like an unmute.

My laptop effectively only has one output, which goes to the internal
speakers by default or, if a jackplug is plugged in, to the line output
socket. There is no digital output.

To find that in order get the audio output to work, I have to unmute the
LFE channel for surround sound, is therefore simply ridiculous.

Given the other things
you've done I'm surprised if you are terrified of a terminal. Your choice,
though. For getting output from internal hardware the fix is probably
simple, and outlined on the pages I wrote as work-throughs.

I am quite happy to use a terminal, having used command-line interfaces
for many years, and find it preferable to using a GUI for some purposes.
The thing that surprised me with Ubuntu was that it appears to be
necessary to use the terminal to configure something as basic as the
sound mixer - something that has been very easy to do using the GUI in
Windows for as long as I can remember.


For something like the EZCap for capture I suspect the problem is harder
as I'm far from sure it identifies itself correctly over USB and then
provides standard LPCM format. Since I don't have one I'll have to defer
beyond that to those who have!


Well, I've now found that alsamixer does recognise my Easycap, but the
operative key is F6 - select sound card - and the Easycap capture device
is then listed as "USB 2.0 Video Capture Controlle".

In article ,
John Legon wrote:
Jim Lesurf wrote:

However, the reality is hardware and user preferences vary a lot. So the
install has to make some guesses or assumptions.
....snips...

A computer operating system worthy of the name shouldn't be making
assumptions, but should identify the hardware it is running on and
configure itself accordingly, presenting options to the user which are
relevant to the hardware.
....snips...

My laptop effectively only has one output, which goes to the internal
speakers by default or, if a jackplug is plugged in, to the line output
socket. There is no digital output.

To find that in order get the audio output to work, I have to unmute the
LFE channel for surround sound, is therefore simply ridiculous.

Scuse me joining in your rant but I think you've highlighted the problem.
The chipsets may be standard (albeit all different) but the ways in which
manufacturers connect it up to inputs and outputs are not. Unless said
cost-cutting buggers are willing to contribute to a database of what
they have done, regularly updated, the software stands no chance.

I do thoroughly agree with the rest of the conclusions about layers of
needlessly complex controls and subsystems. Most of the drivers either
work at a ridiculously low level of exposing individual chipset control
bits (ALSA) or a uselessly high level that assumes all decisions can be
automatically made (e.g. Pulse).

What I feel is missing is a control layer written with reference
to chipset data sheets by a programmer and an audio person who can
simplify by linking controls that are subtly linked to each other
and which are required for other functions (e.g. your LFE control).

It would have a unified view that you didn't need to drill down into
like alsamixer does (unless you wanted to), and it should be as simple as
"which inputs/outputs do I want to enable" and should set all the other
toggles and levels appropriately ... then it would vastly reduce the
hassle of finding out what a particular manufacturer has connected up,
even if that couldn't be identified automatically.

Perhaps one day it will be. In the meantime I also find that loading
alsamixer (or alsamixergui) and turning everything on is the best way
to get sound out of a machine ... at least up to the point where you
find that due to cost cutting, the digital and analogue outputs share
a socket so enabling one disables the other ...

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

Nick Leverton wrote:
[...]

What I feel is missing is a control layer written with reference
to chipset data sheets by a programmer and an audio person who can
simplify by linking controls that are subtly linked to each other
and which are required for other functions (e.g. your LFE control).

[...]

Quite impossible as publicly available datasheets are usually
incomplete. Complete datasheets/prog.manuals are often available only
after signing a NDA. Of course no open-source hacker will sign any NDA,
as he'd violate it by writing open source software.

If you want working drivers, you should use windowze or demand a change
in legislation.

In article , John
Legon
wrote:
Jim Lesurf wrote:
In article , John
Legon wrote:
Jim Lesurf wrote:
[snip]

assumptions!

A computer operating system worthy of the name shouldn't be making
assumptions, but should identify the hardware it is running on and
configure itself accordingly, presenting options to the user which are
relevant to the hardware.

Its a nice theory... but reality tends to be too complex.

So the hardware may have more than output for audio, and the software have
more than one way to play it. The user may want to hear things like 'bongs'
when emails arrive added to music, or they may not. And so on.

So it is inevitable in all by the most trivial cases that the installed OS
and user software will have to either make assumptions *OR* the first time
it is installed/run it will have to ask the user to answer a long series of
questions that must answer. And they may not at that point know what
options they'll want.

So you almost unavoidably have a situation where the install either tries
to guess 'what most people will want' - and get it wrong in some cases. Or
face new users with a list if questions they may be unable to answer.

That said, problems like this can't always be avoided due to the sheer
range of detailed circumstances. Manufacturers can often dodge this by
pre-installing and matching hardware with settings, but that may
*still* provide a setup that doesn't do what a given user wants
out-of-the-box.

What happens with Windows, of course, is that the manufacturers supply
device drivers, which define valid options for the hardware in question.

That may be true. Whereas Linux simply adds the needed code at that level
into the Kernel/modules. However that isn't really the problem. Although of
course commercially sold *packages* of OS+hardware+user software will have
some of this done by the maker.

But often it seems that those manufactures don't provide drivers for
linux, which is left floundering and dependent upon hacking to determine
what needs to be done.

That can happen. Although I'd say it was less of a problem these days now
that people like Intel, etc, contribute to the kernel, etc. The real
problem i there s the sheer diversity of hardware and user preferences.

But as yet it isn't clear to me if that's the cause of your difficulty. May
simply be that you need to do something straightforward, but based on
learning more about what you are trying to use.


Your machine may be 'playing' audio, but via an output you aren't
actually using. Or require a simple change like an unmute.

My laptop effectively only has one output, which goes to the internal
speakers by default or, if a jackplug is plugged in, to the line output
socket. There is no digital output.

What does 'effectively' mean? On my laptop the speakers are separate to the
headphone socket, and so is the HDMI (as well as the optical output).


To find that in order get the audio output to work, I have to unmute the
LFE channel for surround sound, is therefore simply ridiculous.

Your "have" might mean "you don't enough to know any alternative". I can't
tell from the little you've said so far.

Afraid you'd have to be more specific as to the files, user software, etc,
for me to comment in detail. It isn't clear to my that what you say is the
only or simplest solution. May just be a work-around you found that happens
to work in particular circumstances.


Given the other things
you've done I'm surprised if you are terrified of a terminal. Your
choice, though. For getting output from internal hardware the fix is
probably simple, and outlined on the pages I wrote as work-throughs.

I am quite happy to use a terminal, having used command-line interfaces
for many years, and find it preferable to using a GUI for some purposes.
The thing that surprised me with Ubuntu was that it appears to be
necessary to use the terminal to configure something as basic as the
sound mixer - something that has been very easy to do using the GUI in
Windows for as long as I can remember.

Again, you'd have to consider what I've explained. And that you've given us
no real details we could use to see if there is a simpler diagnosis and fix
than the one you've stated.

And I've lost count of the people I've know who complained that a Windows
or Mac setup didn't do what they wanted, etc. Can't see the point of trying
to make this a 'My OS is better than yours'. Either you'd like to
understand the problem and fix it, or not...


For something like the EZCap for capture I suspect the problem is
harder as I'm far from sure it identifies itself correctly over USB
and then provides standard LPCM format. Since I don't have one I'll
have to defer beyond that to those who have!


Well, I've now found that alsamixer does recognise my Easycap, but the
operative key is F6 - select sound card - and the Easycap capture device
is then listed as "USB 2.0 Video Capture Controlle".

If you read the pages I've written, or ask here, I'd be happy to advise.
What wasn't clear to me from your earlier comments was if you wanted to
bother or simply complain about Ubuntu.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf wrote:
In article , John
Legon
wrote:
Jim Lesurf wrote:
In article , John
Legon wrote:
Jim Lesurf wrote:
[snip]

assumptions!

A computer operating system worthy of the name shouldn't be making
assumptions, but should identify the hardware it is running on and
configure itself accordingly, presenting options to the user which are
relevant to the hardware.

Its a nice theory... but reality tends to be too complex.

The reality is too complex for Linux, but not for Windows. In my own
installations of Win2k and XP on several computers (including the laptop
in question), I have gone to the manufacturers' websites and have
downloaded device drivers and utilities specific to the hardware. There
has been no guesswork or making of assumptions - the OS understands the
specific hardware and works the way it is intended to.

Alsa on my laptop, however, has clearly failed to identify the hardware
configuration, and provides mixer controls which serve no purpose. It is
purely by chance that I can get a result at all - by unmuting "LFE".

So the hardware may have more than output for audio, and the software have
more than one way to play it. The user may want to hear things like 'bongs'
when emails arrive added to music, or they may not. And so on.

The chipset may well have outputs that are not implemented, and Windows
running on the same laptop provides no support for them.

So it is inevitable in all by the most trivial cases that the installed OS
and user software will have to either make assumptions *OR* the first time
it is installed/run it will have to ask the user to answer a long series of
questions that must answer. And they may not at that point know what
options they'll want.

So you almost unavoidably have a situation where the install either tries
to guess 'what most people will want' - and get it wrong in some cases. Or
face new users with a list if questions they may be unable to answer.

By default most people want to start with a fully functioning system -
bongs and all! They have the option to turn them off if they want - but
no Windows user would expect to have to fire up a terminal program in
order to toggle a mute control for an obscure surround sound channel
which isn't supported on the machine - just to get basic functionality
for sound whether for alerts or playing music or videos etc..


That said, problems like this can't always be avoided due to the sheer
range of detailed circumstances. Manufacturers can often dodge this by
pre-installing and matching hardware with settings, but that may
*still* provide a setup that doesn't do what a given user wants
out-of-the-box.

What happens with Windows, of course, is that the manufacturers supply
device drivers, which define valid options for the hardware in question.

That may be true. Whereas Linux simply adds the needed code at that level
into the Kernel/modules. However that isn't really the problem. Although of
course commercially sold *packages* of OS+hardware+user software will have
some of this done by the maker.

Linux developers can attempt to add the code but often aren't privy to
the detailed hardware specifications, and can only achieve partial
success by tinkering or hacking Windows drivers etc.
[...]

But as yet it isn't clear to me if that's the cause of your difficulty. May
simply be that you need to do something straightforward, but based on
learning more about what you are trying to use.

Your machine may be 'playing' audio, but via an output you aren't
actually using. Or require a simple change like an unmute.

My laptop effectively only has one output, which goes to the internal
speakers by default or, if a jackplug is plugged in, to the line output
socket. There is no digital output.

What does 'effectively' mean? On my laptop the speakers are separate to the
headphone socket, and so is the HDMI (as well as the optical output).

It's perfectly clear what I mean. There is only one audio output, which
is routed to the internal speakers unless headphones are plugged in.
There is no digital audio output, whether coaxial or optical or HDMI on
the laptop machine.

To find that in order get the audio output to work, I have to unmute the
LFE channel for surround sound, is therefore simply ridiculous.

On Wed, 20 Feb 2013 13:44:31 +0000
John Legon wrote:

Jim Lesurf wrote:
In article , John
Legon
wrote:
Jim Lesurf wrote:

[snip]

Well, whatever. The fact is that a fresh install on my laptop
won't play even Ubuntu's own start-up sound when the desktop
appears after booting because of some obscure and totally
irrelevant setting in an equally obscure audio mixer program that
can only be accessed through a terminal program...

Well, the next fact is that it is then up to you if you want to try
and sort it out or not. :-)

Yes, I've had the same problem. The cure was to bypass Pulse audio
and use ALSA.

However, the reality is hardware and user preferences vary a lot.
So the install has to make some guesses or assumptions. I feel that
additions like Pulse are a PITA (and may be the cause in your
case). Hence my preference to simply use alsa. Magic-wand desktop
GUI software tends to hide what you end up needing. And IMHO the
assumptions distro developers make about audio seem daft to me. But
I can't tell how typical I am of most users. As a hi-fi fanatic I
may be well out of the usual. That said, this seems an insanely
common problem which should be telling developers they are making
the wrong assumptions!

A computer operating system worthy of the name shouldn't be making
assumptions, but should identify the hardware it is running on and
configure itself accordingly, presenting options to the user which
are relevant to the hardware.

That said, problems like this can't always be avoided due to the
sheer range of detailed circumstances. Manufacturers can often
dodge this by pre-installing and matching hardware with settings,
but that may *still* provide a setup that doesn't do what a given
user wants out-of-the-box.

What happens with Windows, of course, is that the manufacturers
supply device drivers, which define valid options for the hardware in
question. But often it seems that those manufactures don't provide
drivers for linux, which is left floundering and dependent upon
hacking to determine what needs to be done.


Your machine may be 'playing' audio, but via an output you aren't
actually using. Or require a simple change like an unmute.

My laptop effectively only has one output, which goes to the internal
speakers by default or, if a jackplug is plugged in, to the line
output socket. There is no digital output.

To find that in order get the audio output to work, I have to unmute
the LFE channel for surround sound, is therefore simply ridiculous.

Given the other things
you've done I'm surprised if you are terrified of a terminal. Your
choice, though. For getting output from internal hardware the fix
is probably simple, and outlined on the pages I wrote as
work-throughs.

I am quite happy to use a terminal, having used command-line
interfaces for many years, and find it preferable to using a GUI for
some purposes. The thing that surprised me with Ubuntu was that it
appears to be necessary to use the terminal to configure something as
basic as the sound mixer - something that has been very easy to do
using the GUI in Windows for as long as I can remember.


For something like the EZCap for capture I suspect the problem is
harder as I'm far from sure it identifies itself correctly over USB
and then provides standard LPCM format. Since I don't have one I'll
have to defer beyond that to those who have!


Well, I've now found that alsamixer does recognise my Easycap, but
the operative key is F6 - select sound card - and the Easycap capture
device is then listed as "USB 2.0 Video Capture Controlle".




I just repeated that, and saw the same, but was then met with the
message:
"This device does not have any playback controls"
which rather confirms the end of the dmesg I posted last night!
F4 shows a Capture volume control bar; but I am otherwise engaged at
the moment. Maybe I will continue with this tomorrow, after all.
--
Davey.