ALSA for audio

Davey wrote:
On Tue, 19 Feb 2013 09:56:45 +0000 (GMT)
Jim wrote:

In ,
wrote:
On Mon, 18 Feb 2013 17:56:45 +0000 (GMT)
Jim wrote:

In , Davey
wrote:

I fixed the no-audio with video clips by disabling the .asoundrc
file!

What did your .asoundrc file contain?

Slainte,

Jim

This (based on your advice):

pcm.!default {
type plug
slave {
pcm "plughw:1,9"
channels 2
}
}

AIUI That specifies the default for output *from* your computer, not
capturing input. IIRC when you use "arecord -l" it told you the EZCap
was hw:2,0,0 for capture. So you need to specify the capture (i.e.
input) device you want seperately from the above.

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.

N.B. Check after a power cycle that the changes you made with
alsamixer *are* still shown. If not, you'll need to follow the advice
about specifically saving and re-loading the alsa state, or using
sudo.

Slainte,

Jim


2nd brief reply. I had already tried the alsamixer/F4 exercise, and it
shows one Capture device whether or not the EZCap is plugged in, no
different. I'm not sure what it is, as there is also a Front Mic Boost
and a Mic Boost, which I assume are the built-in microphone and the
microphone socket. nless it's the Internal card, which is supported
by the fact that it is apparently on the Intel Internal Sound Card.
But I am more and more inclined to the view that this approach is
doomed anyway, as I expressed recently, which is why I moved the player
down to the desktop PC this morning.
I might try with the EXCap plugged into the VCR, without the video
connection, so that will be akin to what I was doing with the cassette
player, but from what I have seen so far, I am not expecting much of
any use.

What does dmesg say?
What kernel messages do you get when you plug in the capture device...
Is it being recognized and modules loaded? which ones?

On Tue, 19 Feb 2013 20:27:26 +0100
Johann Klammer wrote:

Davey wrote:
On Tue, 19 Feb 2013 09:56:45 +0000 (GMT)
Jim wrote:

In ,
wrote:
On Mon, 18 Feb 2013 17:56:45 +0000 (GMT)
Jim wrote:

In , Davey
wrote:

I fixed the no-audio with video clips by disabling the .asoundrc
file!
snip

2nd brief reply. I had already tried the alsamixer/F4 exercise, and
it shows one Capture device whether or not the EZCap is plugged in,
no different. I'm not sure what it is, as there is also a Front Mic
Boost and a Mic Boost, which I assume are the built-in microphone
and the microphone socket. nless it's the Internal card, which is
supported by the fact that it is apparently on the Intel Internal
Sound Card. But I am more and more inclined to the view that this
approach is doomed anyway, as I expressed recently, which is why I
moved the player down to the desktop PC this morning.
I might try with the EXCap plugged into the VCR, without the video
connection, so that will be akin to what I was doing with the
cassette player, but from what I have seen so far, I am not
expecting much of any use.

What does dmesg say?
What kernel messages do you get when you plug in the capture device...
Is it being recognized and modules loaded? which ones?



This would appear to be a fairly definitive statement, from my very
limited understanding of these things:

kernel: [26208.354299] ALSA pcm.c:174: 6:2:2: endpoint lacks sample
rate attribute bit, cannot set.

I think I'll give up here, what with the failed Audacity as well. But
thanks, anyway.

--
Davey.

On Tue, 19 Feb 2013 17:45:52 +0000, Davey wrote:

2nd brief reply. I had already tried the alsamixer/F4 exercise, and it
shows one Capture device whether or not the EZCap is plugged in, no
different. I'm not sure what it is, as there is also a Front Mic Boost
and a Mic Boost, which I assume are the built-in microphone and the
microphone socket. nless it's the Internal card, which is supported by
the fact that it is apparently on the Intel Internal Sound Card. But I
am more and more inclined to the view that this approach is doomed
anyway, as I expressed recently, which is why I moved the player down to
the desktop PC this morning.
I might try with the EXCap plugged into the VCR, without the video
connection, so that will be akin to what I was doing with the cassette
player, but from what I have seen so far, I am not expecting much of any
use.

What does the "lsusb" command say before and after the EXCap is plugged
in and/or switched on?

Look at its manpages too: with no arguments lsusb just outputs a summary
of USB ports and connected devices, but if you use options to ask for
more detail about a specific device you'll get quite some detail. What
this shows can be more useful that watching log entries go past with
"tail -f /var/log/messages" as you plug the device in and turn it on.


--
[email protected] | Martin Gregorie
gregorie. | Essex, UK
org |

Davey wrote:
[...]


This would appear to be a fairly definitive statement, from my very
limited understanding of these things:

kernel: [26208.354299] ALSA pcm.c:174: 6:2:2: endpoint lacks sample
rate attribute bit, cannot set.

I think I'll give up here, what with the failed Audacity as well. But
thanks, anyway.


There must be more than just that one line. The whole discovery process
etc... Once you know what modules get loaded, you can start googling...
some modules may be buggy, some may need options to initialize properly...

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

Davey wrote:

2nd brief reply. I had already tried the alsamixer/F4 exercise, and it
shows one Capture device whether or not the EZCap is plugged in, no
different. I'm not sure what it is, as there is also a Front Mic Boost
and a Mic Boost, which I assume are the built-in microphone and the
microphone socket. nless it's the Internal card, which is supported
by the fact that it is apparently on the Intel Internal Sound Card.
But I am more and more inclined to the view that this approach is
doomed anyway, as I expressed recently, which is why I moved the player
down to the desktop PC this morning.

The device shown is clearly the internal sound card.

I might try with the EXCap plugged into the VCR, without the video
connection, so that will be akin to what I was doing with the cassette
player, but from what I have seen so far, I am not expecting much of
any use.

http://www.linuxtv.org/wiki/index.ph...ture_devi ces

It seems that the Easycap device is often not recognised by alsa. The
solution, supposedly, is to unplug the device, unload the USB sound
module using rmmod snd_usb_audio and try again. I've tried this,
however, and get the response "operation not permitted." The device
still isn't listed in alsamixer.

Using 'lsusb' does, however, report the EasyCAP with ID of 0e51:0408
and 'dmesg' gives the details.

On Wed, 20 Feb 2013 01:57:24 +0100
Johann Klammer wrote:

Davey wrote:
[...]


This would appear to be a fairly definitive statement, from my very
limited understanding of these things:

kernel: [26208.354299] ALSA pcm.c:174: 6:2:2: endpoint lacks sample
rate attribute bit, cannot set.

I think I'll give up here, what with the failed Audacity as well.
But thanks, anyway.


There must be more than just that one line. The whole discovery
process etc... Once you know what modules get loaded, you can start
googling... some modules may be buggy, some may need options to
initialize properly...


Yes, there is more. But:
I think I'll give up here, what with the failed Audacity as well.
But thanks, anyway."
summarises my current position. I have now re-arranged my equipment so
that I can do what I want without spending more time, with very little
prospect of success, on this particular project.
If you really do want to go further, I will post the whole additional
demsg section, but I am not going further along this path myself.
I do appreciate the interest, though.
--
Davey.

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