On Wed, 20 Feb 2013 20:18:44 +0000
Davey wrote:

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

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

[snip]


snip


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.

A little more information:

If I launch alsamixer before ever plugging the EZCap in, then it shows
no Capture L/R volume bar. Plugging in the device then adds it, but
unplugging it does not remove the bar. This probably led me astray
earlier, when I only ran alsamixer after installing the EZCap.

Despite Audacity having failed to launch either from the terminal or
from the Applications menu, I clicked on an old *.au file today, and it
launched Audacity instantly, with the file ready to go. It obviously
needs guidance when opened.
But I still don't know yet whether the EZCap, or the Hauppauge for that
matter, produces a usable audio stream at all.
--
Davey.

In article , Davey
wrote:

Despite Audacity having failed to launch either from the terminal or
from the Applications menu, I clicked on an old *.au file today, and it
launched Audacity instantly, with the file ready to go. It obviously
needs guidance when opened. But I still don't know yet whether the
EZCap, or the Hauppauge for that matter, produces a usable audio stream
at all.

You should be able to investigate that with the arecord command as outlined
in earlier postings. First by using -l and -L to find its card
identification numbers or strings. Then by trying arecord with -D followed
by the relevant numbers/strings and reporting the details of any errors
returned by arecord.

As yet, though, I have no idea if the device you have will provide audio in
a format alsa can recognise.

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

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.

On Thu, 21 Feb 2013 12:23:03 +0000 (GMT)
Jim Lesurf wrote:

In article , Davey
wrote:

Despite Audacity having failed to launch either from the terminal or
from the Applications menu, I clicked on an old *.au file today,
and it launched Audacity instantly, with the file ready to go. It
obviously needs guidance when opened. But I still don't know yet
whether the EZCap, or the Hauppauge for that matter, produces a
usable audio stream at all.

You should be able to investigate that with the arecord command as
outlined in earlier postings. First by using -l and -L to find its
card identification numbers or strings. Then by trying arecord with
-D followed by the relevant numbers/strings and reporting the details
of any errors returned by arecord.

As yet, though, I have no idea if the device you have will provide
audio in a format alsa can recognise.

Slainte,

Jim


Most of that we tried, and I got a silent recording, which led me to
agree with you that it probably doesn't provide a suitable format. At
the moment, I have a system that will record using the desktop's sound
card, and then I can just move the file over to the laptop for working
with Audacity. The laptop's location is much more comfortable than the
desktop's! But I will try again, just to be sure.
--
Davey.

In article , Davey
wrote:
On Thu, 21 Feb 2013 12:23:03 +0000 (GMT) Jim Lesurf
wrote:


You should be able to investigate that with the arecord command as
outlined in earlier postings. First by using -l and -L to find its
card identification numbers or strings. ... [snip]

Most of that we tried, and I got a silent recording, which led me to
agree with you that it probably doesn't provide a suitable format.

Thanks. OK, that's what I thought I recalled, but wasn't sure. Lacking
that, there isn't much point in delving into alsa until such time as the
EZCap might be shown to provide LPCM by some appropriate method. The
problem may not be with alsa, but the (possibly undefined in open info
terms) format it uses.

Some devices (e.g. the FUNcube I'm happily using) does provide the data
stream fine via alsa, despite the values not actually being audio. The
details are open, so easy to deal with.

At the moment, I have a system that will record using the desktop's
sound card, and then I can just move the file over to the laptop for
working with Audacity. The laptop's location is much more comfortable
than the desktop's! But I will try again, just to be sure.

OK. Sorry I can't help with this, but it looks like being a matter of the
device info being unknown and proprietary.

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

On Thu, 21 Feb 2013 16:22:25 +0000 (GMT)
Jim Lesurf wrote:

In article , Davey
wrote:
On Thu, 21 Feb 2013 12:23:03 +0000 (GMT) Jim Lesurf
wrote:


You should be able to investigate that with the arecord command as
outlined in earlier postings. First by using -l and -L to find its
card identification numbers or strings. ... [snip]

Most of that we tried, and I got a silent recording, which led me to
agree with you that it probably doesn't provide a suitable format.

Thanks. OK, that's what I thought I recalled, but wasn't sure. Lacking
that, there isn't much point in delving into alsa until such time as
the EZCap might be shown to provide LPCM by some appropriate method.
The problem may not be with alsa, but the (possibly undefined in open
info terms) format it uses.

Some devices (e.g. the FUNcube I'm happily using) does provide the
data stream fine via alsa, despite the values not actually being
audio. The details are open, so easy to deal with.

At the moment, I have a system that will record using the desktop's
sound card, and then I can just move the file over to the laptop for
working with Audacity. The laptop's location is much more
comfortable than the desktop's! But I will try again, just to be
sure.

OK. Sorry I can't help with this, but it looks like being a matter of
the device info being unknown and proprietary.

Slainte,

Jim


I am now going to take a look at the specific audio-to-USB devices, as
if they are about £10, that makes them economically viable, and would
allow me to do all my transferring in one place. I'll also do some test
editing on Audacity, now that it appears to be launchable on the laptop.
I wonder if there's a market for doing this for money, or does it
require more sophisticated equipment and knowledge?
--
Davey.

In article , Davey
wrote:
On Thu, 21 Feb 2013 16:22:25 +0000 (GMT) Jim Lesurf
wrote:

I am now going to take a look at the specific audio-to-USB devices, as
if they are about £10, that makes them economically viable, and would
allow me to do all my transferring in one place. I'll also do some test
editing on Audacity, now that it appears to be launchable on the laptop.
I wonder if there's a market for doing this for money, or does it
require more sophisticated equipment and knowledge? -

Some people "do it for money" even when the results show they are clueless.
:-)

I've lost count of how many examples I've seen of poorly/idiotically
'mastered' sic commercial recordings. The more kit people have, the more
ways they have to get it wrong.

So if you take care I doubt you could be worse that some of what I've seen
and heard produced by some professional 'experts'...

FWIW I prefer using an external decent-quality digital recorder (Tascam
HD-P2) as it gives excellent results via CF cards. But, yes, it costs a lot
more than the domestic USB audio input dongles around in shops and
catalogues. You may find that one of the cheaper solid-state recorders
works nicely if you just want 48k/16bit, though. Depends on what you're
after.

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.