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.

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


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.

The reality behind that is that one made assumptions that suited you and
the other didn't. :-)

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".

Which may not tell you anything about how the problem might easily be
diagnosed and fixed in a more logical and understandable manner. :-)

What you say does remind me of a story...

Man goes into a garage and complains his new car is faulty as he can only
stop it by opening the door so he can scrape it along a wall.

Questioned by the mechanic, it becomes clear he isn't aware of the foot or
hand brake controls as he is driving without having had any instructions
about controlling a car.

Of course, people these days have to pass a test to be legally allowed to
drive. No such nonsense for computer users. :-)

BTW The above is a version of one of the Mullah Nasrudin Strories.

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.

That may be the standard package arrangement by the makers.


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!

And those supplying have to guess what 'most people' want. Even if 'most'
is sometimes simply the biggest minority...

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..

Yes, you're probably right. That's probably a common attitude for those who
have no concept that Windows isn't a synonim for Computer. Thus the
understandable tendency for those building some Linux distros to try and do
the same 'hide and wave a magic wand' as Windows does to nanny its users.

The problems are simple. Not everyone wants the same thing. Not all
hardware is the same. Not everything is documented or works in a way that
makes sense. Not every user knows what they are doing as if instilled at
birth. etc...

, 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. [...]

Actually in recent years it is more common for commercial makers to either
supply data or adhere to methods that allow 'driverless' use. Modern asynch
USB DACs are a nice example. But problems remain for various murky reasons.



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.

So there is no HDMI or other AV sockets at all? The *only* physical output
socket for audio or video is a headphone jack?

How do you know that the speakers/headphone is switched purely by a
mechanical switch operated by insertion of a plug?

What does 'aplay -l' report?

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.

Unless, of course, there is a simpler and more sensible method you haven't
found and understood... :-)

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

In article , John
Legon wrote:
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.

That's not actually how it works. The OS knows nothing about the
hardware except what the drivers tell it -- if you have the right
drivers then everything should work (that's true for almost any OS, not
just Windows).

There is always a degree of guesswork and assumption-making when you
visit the vendor's website and find drivers for a gazillion models of
hardware but none that has *exactly* the same model number as yours.

Alsa on my laptop, however, has clearly failed to identify the
hardware configuration, and provides mixer controls which serve no
purpose.

Linux sound drivers are a bit more of a black art than hardware drivers
(ALSA forms a layer above the actual hardware drivers, and getting it
configured appropriately is nowhere near as straightforward as getting
hardware drivers to spot their own bits of hardware and install
themselves).

The biggest problem here, it seems to me, is that there are competing
standards (ALSA, OSS, Pulse, whatever) and no common conventions,
interface, or utilities to make them all play (pun intended) nicely
together.

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..

No, with windows it's the other way around -- whenever you install it
you have to spend time turning OFF the inane jingles it likes to play to
itself whenever it starts up and shuts down (and a few more besides).

Somewhere in between that and the ALSA default silence would be nice!

It took me some time, a while ago, to try to get sound over HDMI out of
a Linux nettop thingie ... not only was the sound muted by default on
HDMI, the software needed to unmute it wasn't installed by default.

I agree that that's not very impressive.

Cheers,
Daniel.

On 2013-02-24, Daniel James wrote:
In article , John
Legon wrote:
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.

That's not actually how it works. The OS knows nothing about the
hardware except what the drivers tell it -- if you have the right
drivers then everything should work (that's true for almost any OS, not
just Windows).

There is always a degree of guesswork and assumption-making when you
visit the vendor's website and find drivers for a gazillion models of
hardware but none that has *exactly* the same model number as yours.


Alsa on my laptop, however, has clearly failed to identify the
hardware configuration, and provides mixer controls which serve no
purpose.

Linux sound drivers are a bit more of a black art than hardware drivers
(ALSA forms a layer above the actual hardware drivers, and getting it
configured appropriately is nowhere near as straightforward as getting
hardware drivers to spot their own bits of hardware and install
themselves).

Alsa actually is the hardware drivers. pulse is a layer above alsa (like
Jack). OSS
is a different set of drivers. alsa has an oss emulation layer.

The problem is not so much that they do not play together. The problem
is that sound card manufacturers are both proprietary (I emember writing
to MAudio about their Transit card, and asking which file on Windows was
the firmware file. They wrote back and said this was proprietary
information and refused to tell me.) and irresponsible ( all feel that
they have the right and duty to make their soundcards completely
different from and incompatible with every other card out there.
They make sure that they write a driver so that their card works in
Windows, and maybe osx, but that is it.


The biggest problem here, it seems to me, is that there are competing
standards (ALSA, OSS, Pulse, whatever) and no common conventions,
interface, or utilities to make them all play (pun intended) nicely
together.

Pulse was an attempt to make a common convention, a common API that all
programs could use. Of course then it has to speak to alsa to actually
drive the cards. And of course it introduces its own layer of bugs.







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..

Scream at the manufacturers of your sound card.


No, with windows it's the other way around -- whenever you install it
you have to spend time turning OFF the inane jingles it likes to play to
itself whenever it starts up and shuts down (and a few more besides).

totally different layer from the soundcards.


Somewhere in between that and the ALSA default silence would be nice!

It took me some time, a while ago, to try to get sound over HDMI out of
a Linux nettop thingie ... not only was the sound muted by default on
HDMI, the software needed to unmute it wasn't installed by default.

I agree that that's not very impressive.

Cheers,
Daniel.