sound problems on Debian unstable

I'm having some perplexing sound problems on my Debian unstable system and
would like to ask for help, clarifications and sympathy :)

The system is a Dell Optiplex GX1 that's been somewhat modified (BIOS
update, Powerleap processor, maxed out for RAM, extra hard drives, new
power supply). It's one of those institutional models with a daughterboard
that has some pci and isa slots in it. It has a "PnP BIOS" according to
dmesg output.

It has onboard sound--Crystal Semiconductor--that I've had working fine
under other Linux installs to this machine. But in this case, I wanted to
add a sound card, since I'll be using unpowered speakers and need the
computer to output more amplified sound.

I put in an ISA card--a Logitech Soundman 16. It is an older, though never
used, card. I tried isapnptools to get the thing recognized, but pnpdump
reports "no boards found." Searching the internet I finally found the
right module to load for the card--pas2. After loading that module with
necessary io/irq/dma specifications, I was able to play a CD. A tape deck
and radio, played through the audio-in port on the card, worked fine as
well. Nice sound. However, my sound apps, like Rhythmbox (I'm using the
Gnome desktop on this machine), will not really play. What I mean by "not
really play" is that I get some really choppy sound: split-second snippets
of the actual music interspersed with some clicking noises and punctuated
by silence. dmesg output shows some errors after trying Rhythmbox, as
follows: "Sound: DMA (output) timed out - IRQ/DRQ config error?" Kind of
wierd.

cat /proc/interrupts shows the right interrupt assigned to the module (I
was using IRQ 7 but dmesg indicated that the parallel port was trying to
use 7 so I switched the sound card to IRQ 5 using the DOS utility that
came with the card). cat /proc/ioports does not show the assigned io
(230--it was 220 but I assigned a different one last night using the DOS
software that came with the card in hopes this might resolve the problem)
associated with the module. This holds for both the 220 setting I used
earlier as well as the current 230 setting. I can include the full ouput
from those commands in a future post if that would be helpful in
diagnosing.

I wondered if the PnP BIOS Linux identifies might not be the problem, and
whether it might be blocking Linux and isapnptools from dealing with the
card as specified or detecting it. But this doesn't seem to make sense
since I am able to run the test software under DOS provided with the card
with no problems. I boot from a DOS diskette that sets up a ramdisk, and I
install the soundman testing utilities in the ramdisk. I can hear all the
sounds fine, fiddle with IRQ's, IO's and DMA's, run the diagnostic which
tells me everything is ok. So it's a bit mystifying why Linux can't seem
to deal with the thing.

Maybe it's a sound server issue rather than a hardware issue? I don't
understand very well the various sound server schemes Linux uses, but can
try and answer some pointed questions or run some commands relevant to
this line of inquiry.

Another confusing thing about the card itself is its available settings.
It has 2 possible sets of IRQ's, for example: a "soundman" IRQ and a
"soundblaster" IRQ. Same for DMA setting. But it has *only* a soundblaster
IO. It is said in the manual to be "soundblaster (and adlib) compatible,"
whatever that means.

Input on this problem will be appreciated. Can I make my sound apps play
through this thing, or should I give up and try to find a different card?

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 10:10 AM 4/6/2005 -0500, James Miller wrote:
>I'm having some perplexing sound problems on my Debian unstable system and
>would like to ask for help, clarifications and sympathy :)

I can at least offer the last. Getting sound right ... particularly with
offbeat hardware ... can be a real pain. I confess that about 1/3 of the
time, I end up giving in and buying a reasonably standard, well-supported
sound card, when I run into these messes (usually with on-mobo sound
hardware causing recording, not playback, problems).

>The system is a Dell Optiplex GX1 that's been somewhat modified (BIOS
>update, Powerleap processor, maxed out for RAM, extra hard drives, new
>power supply). It's one of those institutional models with a daughterboard
>that has some pci and isa slots in it. It has a "PnP BIOS" according to
>dmesg output.

Ah yes ... I remember these well. But not fondly. Had an old one
(PentiumPro) and it was nothing but trouble.

>It has onboard sound--Crystal Semiconductor--that I've had working fine
>under other Linux installs to this machine. But in this case, I wanted to
>add a sound card, since I'll be using unpowered speakers and need the
>computer to output more amplified sound.
>
>I put in an ISA card--a Logitech Soundman 16. It is an older, though never
>used, card. I tried isapnptools to get the thing recognized, but pnpdump
>reports "no boards found." Searching the internet I finally found the
>right module to load for the card--pas2.

> After loading that module with necessary io/irq/dma specifications,

You might want to check that you are using the right parameters (the doc
file that comes with kernel source offers sort of an example, in the form
of a LILO append line to use with compiled-in sound, and it indicates the
need to specify two distinct io ports:

append="pas2=0x388,10,3,-1,0x220,5,1,-1 sb=0x220,5,1,-1 opl3=0x388"
).

>I was able to play a CD.
> A tape deck and radio, played through the audio-in port on the card,
> worked fine as well. Nice sound.

All of this has nothing to do with the Linux sound driver. It just confirms
that you have working hardware. But you know that from the DOS boots you
mention below.

>However, my sound apps, like Rhythmbox (I'm using the Gnome desktop on
>this machine), will not really play. What I mean by "not really play" is
>that I get some really choppy sound: split-second snippets of the actual
>music interspersed with some clicking noises and punctuated by silence.
>dmesg output shows some errors after trying Rhythmbox, as follows: "Sound:
>DMA (output) timed out - IRQ/DRQ config error?" Kind of wierd.

I'm more curious by what you mean by "like". It is probably not an issue,
but you might test using a more basic, CLI-oriented app (like mpg123 or
ogg123, depending on what format your source files are). Also, have you
used a sound setup app, for example rexima, to check the card/driver
settings as Linux sees them?

>cat /proc/interrupts shows the right interrupt assigned to the module (I
>was using IRQ 7 but dmesg indicated that the parallel port was trying to
>use 7 so I switched the sound card to IRQ 5 using the DOS utility that
>came with the card).

Is the assignment solo or shared? Did you disable the on-mobo sound in BIOS?

>cat /proc/ioports does not show the assigned io (230--it was 220 but I
>assigned a different one last night using the DOS software that came with
>the card in hopes this might resolve the problem) associated with the
>module. This holds for both the 220 setting I used earlier as well as the
>current 230 setting. I can include the full ouput from those commands in a
>future post if that would be helpful in diagnosing.

The ioport should be showing up, as you no doubt realize. Are you
specifying both pas_io -AND- mss_io when you insmod (or modprobe) the
module? (I'm not familiar with this card or driver, so I don't know which
of them matters to sound playback.)

Could there really be a DMA issue (I've never run into this myself)? What
does "more /proc/dma" tell you?

>I wondered if the PnP BIOS Linux identifies might not be the problem, and
>whether it might be blocking Linux and isapnptools from dealing with the
>card as specified or detecting it. But this doesn't seem to make sense
>since I am able to run the test software under DOS provided with the card
>with no problems. I boot from a DOS diskette that sets up a ramdisk, and I
>install the soundman testing utilities in the ramdisk. I can hear all the
>sounds fine, fiddle with IRQ's, IO's and DMA's, run the diagnostic which
>tells me everything is ok. So it's a bit mystifying why Linux can't seem
>to deal with the thing.

As best as I can tell from what you write, this card does not support PnP
assignment. If you are running isapnptools, by all means do not do so ...
let the BIOS handle everything. But I doubt it is relevant.

>Maybe it's a sound server issue rather than a hardware issue? I don't
>understand very well the various sound server schemes Linux uses, but can
>try and answer some pointed questions or run some commands relevant to
>this line of inquiry.
>
>Another confusing thing about the card itself is its available settings.
>It has 2 possible sets of IRQ's, for example: a "soundman" IRQ and a
>"soundblaster" IRQ. Same for DMA setting. But it has *only* a soundblaster
>IO. It is said in the manual to be "soundblaster (and adlib) compatible,"
>whatever that means.
>
>Input on this problem will be appreciated. Can I make my sound apps play
>through this thing, or should I give up and try to find a different card?

Were it me, I'd give up and buy a more up-to-date card. But I'm lazy and
live near Fry's, where this stuff is always cheap. YMMV.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

Thanks for your response Ray. I've been able to get a little closer to
normal sound by following your advice. But it's not fully functional yet:
using mp3blaster I can get pretty much continuous sound playing
mp3's/ogg's. Pretty much meaning it is continuous and normal (maybe a bit
of scratchiness here and there) until I open an application, switch VT's
or someone sends me an instant message (gaim is running). Then, sound
stops or pauses, continuing where it left off before the other activity
started. I have pretty much the same results using Rhythmbox, but the
scratchiness and pausing seems more severe. So, it's not quite working
right yet. Here's what I did.

On Wed, 6 Apr 2005, Ray Olszewski wrote:

> You might want to check that you are using the right parameters (the doc file
> that comes with kernel source offers sort of an example, in the form of a
> LILO append line to use with compiled-in sound, and it indicates the need to
> specify two distinct io ports:
>
> append="pas2=0x388,10,3,-1,0x220,5,1,-1 sb=0x220,5,1,-1 opl3=0x388"

I got the kernel source and took a look at that file. I'm not sure how to
translate this, though. I'm not using lilo, but Grub. Would Grub take such
parameters and in the exact same form? I've found Grub documentation in
the past to be pretty worthless for clarifying these sorts of things. I'll
see if I can find anything new.

Meantime, I had been specifying io/irq/dma in /etc/modules. Doing my own
sort of freeform adaptation of the information from the kernel
documentation I entered the following lines in /etc/modules:

pas2 io=0x388 irq=3 dma=5
sb io=0x230 irq=5 dma=1

With these parameters I got the sorta kinda working sound situation I
described above. io=0x388 I took from the docs; nothing in my DOS setup
program indicates this as any kind of valid io for the card. The only io
the card documentation (as opposed to kernel documentation) allows for the
card is called "soundblaster port." It is set to 0x230. Likewise I've set
"soundblaster irq" to 5 using the DOS utility and "soundblaster dma" to 1
using the same. Hence the settings for the sb module above. I was
previously *not* loading the sb module, but only tried it this last time.
lsmod shows the sb_lib module loaded, but not the sb module.

The settings I've entered for the pas2 module are the so-called "soundman"
settings. I selected a "soundman irq" of 3 using the DOS utility and a
"soundman dma" of 5. This gets it sorta kinda working. But I do still get
the "Sound: DMA (output) timed out - IRQ/DRQ config error" lines at the
end of dmesg output


> I'm more curious by what you mean by "like". It is probably not an issue, but
> you might test using a more basic, CLI-oriented app (like mpg123 or ogg123,
> depending on what format your source files are). Also, have you used a sound
> setup app, for example rexima, to check the card/driver settings as Linux
> sees them?

I tried mp3blaster, as indicated above. Should this suffice? I apt-get'd
rexima. The various controls show up when I start it and volume and other
levels look ok. Is this what you were after?

> Is the assignment solo or shared? Did you disable the on-mobo sound in BIOS?

The assignment is solo according to cat /proc/interrupts. I *did* disable
onboard sound in the BIOS, yes.

> The ioport should be showing up, as you no doubt realize. Are you specifying
> both pas_io -AND- mss_io when you insmod (or modprobe) the module? (I'm not
> familiar with this card or driver, so I don't know which of them matters to
> sound playback.)

No. I specified io as above--io=XXX after the name of the module I load in
/etc/modules. I have no idea what mss is. I have not run across pas_io or
mss_io. Are you saying that I should put a line like pas_io=0x388 in my
/etc/modules file? And maybe a mss_io=??? there too? pas_io seems fairly
clear: it looks like the same acronym after which the module I load is
named. mss I'll have to look into some more. I wish I knew where to look
for this information. So far I've found bits and pieces scattered across
the internet: it doesn't add up to anything like a comprehensive
picture--much less a coherent solution.

> Could there really be a DMA issue (I've never run into this myself)? What
> does "more /proc/dma" tell you?

me@mymachine:~$ more /proc/dma
4: cascade
5: PAS16

> As best as I can tell from what you write, this card does not support PnP
> assignment. If you are running isapnptools, by all means do not do so ... let
> the BIOS handle everything. But I doubt it is relevant.

I'll go ahead and uninstall isapnptools. I don't have any other need for
it on this machine.

> Were it me, I'd give up and buy a more up-to-date card. But I'm lazy and
> live near Fry's, where this stuff is always cheap. YMMV.

I'm moving somewhat closer to that option. Had I to lived closer to Fry's,
the scales might have been already tipped.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 01:38 PM 4/6/2005 -0500, James Miller wrote:
[...]
>>You might want to check that you are using the right parameters (the doc
>>file that comes with kernel source offers sort of an example, in the form
>>of a LILO append line to use with compiled-in sound, and it indicates the
>>need to specify two distinct io ports:
>>
>> append="pas2=0x388,10,3,-1,0x220,5,1,-1 sb=0x220,5,1,-1 opl3=0x388"
>
>I got the kernel source and took a look at that file. I'm not sure how to
>translate this, though. I'm not using lilo, but Grub. Would Grub take such
>parameters and in the exact same form? I've found Grub documentation in
>the past to be pretty worthless for clarifying these sorts of things. I'll
>see if I can find anything new.
>
>Meantime, I had been specifying io/irq/dma in /etc/modules. Doing my own
>sort of freeform adaptation of the information from the kernel
>documentation I entered the following lines in /etc/modules:
>
>pas2 io=0x388 irq=3 dma=5
>sb io=0x230 irq=5 dma=1

You are pretty much doing what I meant to be suggesting. You do need to
adapt this stuf to /etc/modules, not to grub.

Note though that the LILO parameters associate ioport 0x220 (and the
related dma and int settings) with both pas2 and sb. I'm not sure what to
make of that either ... but my best *guess* from reading the doc file is
that you are not enabling SB emulation (and you probably want to) ... look
at the example for *not* enabling SB in the doc and you'll probably see
what I mean.

What to do about it? You probably need to include a second set of arguments
on the pas2 line, probably labeled sb_io and so forth ... to judge from
this short excerpt from the driver source(./drivers/sound/pas2_card.c):

cfg.io_base = io;
cfg.irq = irq;
cfg.dma = dma;
cfg.dma2 = dma16;

cfg2.io_base = sb_io;
cfg2.irq = sb_irq;
cfg2.dma = sb_dma;
cfg2.dma2 = sb_dma16;

(When the docs are badly written ... and the ones for this driver certainly
are, if only because they do not include a list of legal module arguments
.... there's no substitute for reading the source.)

Also note (this part *is* in the docs) that SB emulation with this card
uses dsp1 and audio1, while native-mode is dsp0 and audio0 ... you may want
to change which sound device are outputting to, since I'd bet the SB
emulation is better behaved than native mode.

Finally, it is unclear to me whether this extended argument list replaces
or combines with the "sb" line you have. I'd try it both ways and see what
works.

But please remember, James, this is all an no more than an extended guess
.... something that might guide you experimenting a bit if you want to spend
the time on it. Nothing more.


>With these parameters I got the sorta kinda working sound situation I
>described above. io=0x388 I took from the docs; nothing in my DOS setup
>program indicates this as any kind of valid io for the card. The only io
>the card documentation (as opposed to kernel documentation) allows for the
>card is called "soundblaster port." It is set to 0x230. Likewise I've set
>"soundblaster irq" to 5 using the DOS utility and "soundblaster dma" to 1
>using the same. Hence the settings for the sb module above. I was
>previously *not* loading the sb module, but only tried it this last time.
>lsmod shows the sb_lib module loaded, but not the sb module.
>
>The settings I've entered for the pas2 module are the so-called "soundman"
>settings. I selected a "soundman irq" of 3 using the DOS utility and a
>"soundman dma" of 5. This gets it sorta kinda working. But I do still get
>the "Sound: DMA (output) timed out - IRQ/DRQ config error" lines at the
>end of dmesg output

Is there any better context fo this message than what you've provided?
Anything before it that refers to the native-mode values (io-0x388 and so
on)? I'd guess this message is telling you that the sb driver cannot find
anything to connect to.

>>I'm more curious by what you mean by "like". It is probably not an issue,
>>but you might test using a more basic, CLI-oriented app (like mpg123 or
>>ogg123, depending on what format your source files are). Also, have you
>>used a sound setup app, for example rexima, to check the card/driver
>>settings as Linux sees them?
>
>I tried mp3blaster, as indicated above. Should this suffice? I apt-get'd
>rexima. The various controls show up when I start it and volume and other
>levels look ok. Is this what you were after?

Yes to all your questions here.

>>Is the assignment solo or shared? Did you disable the on-mobo sound in BIOS?
>
>The assignment is solo according to cat /proc/interrupts. I *did* disable
>onboard sound in the BIOS, yes.
>
>>The ioport should be showing up, as you no doubt realize. Are you
>>specifying both pas_io -AND- mss_io when you insmod (or modprobe) the
>>module? (I'm not familiar with this card or driver, so I don't know which
>>of them matters to sound playback.)
>
>No. I specified io as above--io=XXX after the name of the module I load in
>/etc/modules. I have no idea what mss is. I have not run across pas_io or
>mss_io. Are you saying that I should put a line like pas_io=0x388 in my
>/etc/modules file? And maybe a mss_io=??? there too? pas_io seems fairly
>clear: it looks like the same acronym after which the module I load is
>named. mss I'll have to look into some more. I wish I knew where to look
>for this information. So far I've found bits and pieces scattered across
>the internet: it doesn't add up to anything like a comprehensive
>picture--much less a coherent solution.

Sorry; this was just carelessness on my part. I mistakenly looked at the
docs for the PSS module first, and when I caught my error, I missed fixing
this part.

[rest deleted]


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, Ray Olszewski wrote:

> At 01:38 PM 4/6/2005 -0500, James Miller wrote:
> pas2 io=0x388 irq=3 dma=5
>> sb io=0x230 irq=5 dma=1
>
> You are pretty much doing what I meant to be suggesting. You do need to adapt
> this stuf to /etc/modules, not to grub.
>
> Note though that the LILO parameters associate ioport 0x220 (and the related
> dma and int settings) with both pas2 and sb. I'm not sure what to make of
> that either ... but my best *guess* from reading the doc file is that you are
> not enabling SB emulation (and you probably want to) ... look at the example
> for *not* enabling SB in the doc and you'll probably see what I mean.
>
> What to do about it? You probably need to include a second set of arguments
> on the pas2 line, probably labeled sb_io and so forth ... to judge from this
> short excerpt from the driver source(./drivers/sound/pas2_card.c):
>
> cfg.io_base = io;
> cfg.irq = irq;
> cfg.dma = dma;
> cfg.dma2 = dma16;
>
> cfg2.io_base = sb_io;
> cfg2.irq = sb_irq;
> cfg2.dma = sb_dma;
> cfg2.dma2 = sb_dma16;
>
> (When the docs are badly written ... and the ones for this driver certainly
> are, if only because they do not include a list of legal module arguments ...
> there's no substitute for reading the source.)
>
> Also note (this part *is* in the docs) that SB emulation with this card uses
> dsp1 and audio1, while native-mode is dsp0 and audio0 ... you may want to
> change which sound device are outputting to, since I'd bet the SB emulation
> is better behaved than native mode.
>
> Finally, it is unclear to me whether this extended argument list replaces or
> combines with the "sb" line you have. I'd try it both ways and see what
> works.

With the separate sb line as in my last post, here's what I get in dmesg
about the module:

Apr 6 12:45:13 localhost kernel: Pro Audio Spectrum driver Copyright (C)
by Hannu Savolainen 1993-1996
Apr 6 12:45:13 localhost kernel: sb: Init: Starting Probe...
Apr 6 12:45:13 localhost kernel: sb: Probing legacy card with io=230,
irq=5, dma=1, dma16=-1
Apr 6 12:45:13 localhost kernel: sb: dsp reset failed.
Apr 6 12:45:13 localhost kernel: sb: Init: Done
Apr 6 12:45:13 localhost kernel: Capability LSM initialized

With sb_irq=XXX (and so forth) in the same line as pas2, I do not get
these sorts of error messages. Just a clean:
Pro Audio Spectrum driver Copyright (C) by Hannu Savolainen 1993-1996

But sound still works very poorly. Very scratchy when I play mp3's/ogg's
with pauses when I open an application, switch terminals or some other
computer activity takes place.

Here's one interesting side-note. Among the things I read I found
reference to the opl3 module with the io=0x388 parameter. Thought I'd add
that in as well (to /etc/modules). It did not cause any sort of error
messages. But most interestingly, where pas2 does not seem to get
associated with an io (according to cat /proc/ioports output)--no matter
whether I specify 0x230 or 0x388--opl3 does, in fact, get associated with
io 0x388 when I load this module as specified (again, according to cat
/proc/ioports output).

Changing which sound device output goes to seems worth testing. Only
problem is I have no idea how to do it. Bet it's not a system-wide
setting, but something that needs to be input for each application.

> But please remember, James, this is all an no more than an extended guess ...
> something that might guide you experimenting a bit if you want to spend the
> time on it. Nothing more.

A trip over to Frys (or the local equivalent) is getting more tempting all
the time. Any recommendations for reasonably-priced, Linux-compatible
cards? I'm no kind of audiophile: heck, if I were, I wouldn't be using a
computer to listen to sound. Just something serviceable. I'm happy with
the "sound quality" (I being a former audiophile I use that phrase
loosely) I get out of a Soundblaster awe 64 on my other machine.

> Is there any better context fo this message than what you've provided?
> Anything before it that refers to the native-mode values (io-0x388 and so
> on)? I'd guess this message is telling you that the sb driver cannot find
> anything to connect to.

Not really. These lines (they repeat 6 or 7 times) come at the end of
dmesg, right after information about my video card. They are still there,
even though sound is working somewhat more coherently than it was formerly
(when all I could hear was a snippet of music punctuated by clicks and
moments of silence)

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, James Miller wrote:

> On Wed, 6 Apr 2005, Ray Olszewski wrote:
>
>
> With sb_irq=XXX (and so forth) in the same line as pas2, I do not get these
> sorts of error messages. Just a clean:
> Pro Audio Spectrum driver Copyright (C) by Hannu Savolainen 1993-1996
>
> But sound still works very poorly. Very scratchy when I play mp3's/ogg's with
> pauses when I open an application, switch terminals or some other computer
> activity takes place.
>

Are you sure your soundcard is not sharing interrupts with other device ?



--
?


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:

> On Wed, 6 Apr 2005, James Miller wrote:
>
> Are you sure your soundcard is not sharing interrupts with other device ?

Not totally, no. cat /pro/interrupts shows only PAS16 assigned to IRQ 3.
But dmesg output has ttyS1 using IRQ 3. It's a bit confusing to me. I
assigned it IRQ 3 because previously, when checking cat /proc/interrupts
output I was not even seeing 3 listed. There's nothing hooked to ttyS1
btw. I suppose it's one of the machine's 2 serial ports.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, James Miller wrote:

> On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:
>
>> On Wed, 6 Apr 2005, James Miller wrote:
>>
>> Are you sure your soundcard is not sharing interrupts with other device ?
>
> Not totally, no. cat /pro/interrupts shows only PAS16 assigned to IRQ 3. But
> dmesg output has ttyS1 using IRQ 3. It's a bit confusing to me. I assigned it
> IRQ 3 because previously, when checking cat /proc/interrupts output I was not
> even seeing 3 listed. There's nothing hooked to ttyS1 btw. I suppose it's one
> of the machine's 2 serial ports.
>

This could be the problem. Interrupt 3 is allways assigned to serial port
afaik.
Try to use another interrupt for the sound card.


--
?


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:

> On Wed, 6 Apr 2005, James Miller wrote:
>>
>> Not totally, no. cat /pro/interrupts shows only PAS16 assigned to IRQ 3.
>> But dmesg output has ttyS1 using IRQ 3. It's a bit confusing to me. I
>> assigned it IRQ 3 because previously, when checking cat /proc/interrupts
>> output I was not even seeing 3 listed. There's nothing hooked to ttyS1 btw.
>> I suppose it's one of the machine's 2 serial ports.
>
> This could be the problem. Interrupt 3 is allways assigned to serial port
> afaik.
> Try to use another interrupt for the sound card.

There's no other available IRQ as far as I can tell. I do have the option
of turning off the port in the BIOS which, I suppose, could affect things.
Before trying anything like that though I should mention that sound played
through this card from the CD is flawless (or as flawless as sound from an
old soundcard playing through dimestore speakers can be). It's only when
trying to play from sound apps with music stored on the harddrive that I
get the distortion I've been describing. Still think it's an IRQ problem?

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, James Miller wrote:

> On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:
>
>> On Wed, 6 Apr 2005, James Miller wrote:
>>>
>>> Not totally, no. cat /pro/interrupts shows only PAS16 assigned to IRQ 3.
>>> But dmesg output has ttyS1 using IRQ 3. It's a bit confusing to me. I
>>> assigned it IRQ 3 because previously, when checking cat /proc/interrupts
>>> output I was not even seeing 3 listed. There's nothing hooked to ttyS1
>>> btw. I suppose it's one of the machine's 2 serial ports.
>>
>> This could be the problem. Interrupt 3 is allways assigned to serial port
>> afaik.
>> Try to use another interrupt for the sound card.
>
> There's no other available IRQ as far as I can tell. I do have the option of
> turning off the port in the BIOS which, I suppose, could affect things.
> Before trying anything like that though I should mention that sound played
> through this card from the CD is flawless (or as flawless as sound from an
> old soundcard playing through dimestore speakers can be). It's only when
> trying to play from sound apps with music stored on the harddrive that I get
> the distortion I've been describing. Still think it's an IRQ problem?
>

Afaik playing sound from the CD through soundcard doesn't involve
software. It still looks like an IRQ problem.

Can you post your /proc/interrupts here ?

Also if your soundcard is an ISA one and your BIOS allow you, you can play
with the way BIOS assign IRQ to devices (ISA/PCI or PCI) but this could be
a dangerous thing if you don't know what you are doing.
On a normal system interrupts 0, 1, 2, 3, 4, 7 are normally assigned to
ISA devices and 14 and 15 to PCI IDE. The rest of them depends of the
configuration of the machine.
I usually saw that IRQ 5 or IRQ 9 was used by older soundcards.


--
?


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 04:13 PM 4/6/2005 -0500, James Miller wrote:
[...]
>With sb_irq=XXX (and so forth) in the same line as pas2, I do not get
>these sorts of error messages. Just a clean:
>Pro Audio Spectrum driver Copyright (C) by Hannu Savolainen 1993-1996
>
>But sound still works very poorly. Very scratchy when I play mp3's/ogg's
>with pauses when I open an application, switch terminals or some other
>computer activity takes place.

One thing you don't mention trying is using a different audio device. I
suggest you try directing output to /dev/audio1 or /dev/dsp1 and see if
that improves the result. I don't know how to do that with mp3blaster; with
mpg123 you would do

mpg123 -a /dev/dsp1 nameoffile.mp3

With ogg123, you'd do:

ogg123 -d oss -o dsp:/dev/dsp1 nameoffile.ogg

BTW, the other poster who suggested a problem with your use of IRQ3 may be
right. If so, the use of dsp1 may fix that too, since you have SB emulation
associated with IRQ5.

[...]
>A trip over to Frys (or the local equivalent) is getting more tempting all
>the time. Any recommendations for reasonably-priced, Linux-compatible
>cards? I'm no kind of audiophile: heck, if I were, I wouldn't be using a
>computer to listen to sound. Just something serviceable. I'm happy with
>the "sound quality" (I being a former audiophile I use that phrase
>loosely) I get out of a Soundblaster awe 64 on my other machine.

It's been almost 2 years since I set up a Linux system using new hardware,
but back then, I tried to get SoundBlaster16 cards (usually around $25 back
then). They use the OSS es1371 driver (usually compiled in stock kernels, I
think) and work pretty well for both recording and playback. I've also used
a Yamaha card and been happy with it.




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:

> Can you post your /proc/interrupts here ?

me@mymachine:~$ cat /proc/interrupts
CPU0
0: 25759543 XT-PIC timer
1: 23960 XT-PIC i8042
2: 0 XT-PIC cascade
3: 5223 XT-PIC PAS16
7: 1 XT-PIC parport0
8: 1 XT-PIC rtc
10: 50736 XT-PIC eth0
11: 283557 XT-PIC uhci_hcd
12: 51870 XT-PIC i8042
14: 29656 XT-PIC ide0
15: 493057 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
me@mymachine:~$

> Also if your soundcard is an ISA one and your BIOS allow you, you can play
> with the way BIOS assign IRQ to devices (ISA/PCI or PCI) but this could be a
> dangerous thing if you don't know what you are doing.
> On a normal system interrupts 0, 1, 2, 3, 4, 7 are normally assigned to ISA
> devices and 14 and 15 to PCI IDE. The rest of them depends of the
> configuration of the machine.
> I usually saw that IRQ 5 or IRQ 9 was used by older soundcards.

ISA soundcard, yes. Like I said earlier in this thread the BIOS is
reported as PnP by Linux. Very limited tweaking there--certainly nothing
as advanced as setting IRQ's. I'm afraid my only options are to either set
a different IRQ on the soundcard using the DOS software (though I see no
free IRQ's in range) or to disable ttyS1 (COM 2 as the BIOS sees it, I
believe) and see if that relieves any potential IRQ 3 conflict. Possible
IRQ's for the card are: 2, 3, 5, 7, 10, 11, 12, 15 for "Soundman" and 2,
3, 5, and 7 for "Sound blaster."

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, Ray Olszewski wrote:

> One thing you don't mention trying is using a different audio device. I
> suggest you try directing output to /dev/audio1 or /dev/dsp1 and see if that
> improves the result. I don't know how to do that with mp3blaster; with mpg123
> you would do
>
> mpg123 -a /dev/dsp1 nameoffile.mp3
>
> With ogg123, you'd do:
>
> ogg123 -d oss -o dsp:/dev/dsp1 nameoffile.ogg

I get the following when trying this:

me@mymachine:~/MyMusic$ sudo mpg123 -a /dev/audio1 03\ -\ Norman\ Blake\ \
\ You\ Are\ My\ Sunshine.ogg
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.59q (2002/03/23). Written and copyrights by Joe Drew.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!

Playing MPEG stream from 03 - Norman Blake You Are My Sunshine.ogg ...
MPEG 1.0 layer I, 34381 kbit/s, 32000 Hz mono
Can't open libao driver with device /dev/audio1 (is device in use?)
me@mymachine:~/MyMusic$ sudo mpg123 -a /dev/dsp1 03\ -\ Norman\ Blake\ \ \
You\ Are\ My\ Sunshine.ogg
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3.
Version 0.59q (2002/03/23). Written and copyrights by Joe Drew.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!

Playing MPEG stream from 03 - Norman Blake You Are My Sunshine.ogg ...
MPEG 1.0 layer I, 34381 kbit/s, 32000 Hz mono
Can't open libao driver with device /dev/dsp1 (is device in use?)
me@mymachine:~/MyMusic$

or:

me@mymachine:~/MyMusic$ sudo ogg123 -d oss -o dsp:/dev/audio1 03\ -\
Norman\ Blake\ \ \ You\ Are\ My\ Sunshine.ogg

Audio Device: OSS audio driver output

Playing: 03 - Norman Blake You Are My Sunshine.ogg
Ogg Vorbis stream: 2 channel, 44100 Hz
Title: Norman Blake / You Are My Sunshine
Artist: Various
Track number: 3
Tracktotal: 19
Album: O Brother, Where Art Thou?
Comment: Ripped with Sound Juicer
Error: Cannot open device oss.

me@mymachine:~/MyMusic$

Same error messages whether I try /dev/dsp1 or /dev/audio1, though my
examples here show only output from trying /dev/audio1.

> It's been almost 2 years since I set up a Linux system using new hardware,
> but back then, I tried to get SoundBlaster16 cards (usually around $25 back
> then). They use the OSS es1371 driver (usually compiled in stock kernels, I
> think) and work pretty well for both recording and playback. I've also used a
> Yamaha card and been happy with it.

Thanks for the feedback on that. I'll probably go that route before too
much longer.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, James Miller wrote:

> range) or to disable ttyS1 (COM 2 as the BIOS sees it, I believe) and see if
> that relieves any potential IRQ 3 conflict.

I tried disabling COM 2 in the BIOS (set it to "off" there). When I look
at dmesg output, it does, indeed, appear to be off and is not getting
assigned an IRQ by Linux. I see in dmesg output only ttyS0, assigned IRQ
4. So it seems I have succeeded in freeing up IRQ 3 and resolving any
potential conflict over it that might be contributing to sound issues.
Nonetheless, the sound is of the same poor quality when I try to play
files stored on the hard drive with mp3blaster. It is scratchy and I get
pauses when some other computer activity occurs, just like before. I
therefore presume that IRQ conflicts are not the operative problem here.

I see no io address associated with the sound module(s) in cat
/proc/ioports output, so that could be part of my problem. I also do not
see IRQ 5 associated with anything (or even listed) in cat
/proc/interrupts output, though I've tried to associate the pas2 module
with it by specifying sb_irq=5 (among other parameters) in /etc/modules. I
don't see the device files Ray mentioned as being used by Soundblaster
emulation (/dev/dsp1 or /dev/audio1) in the /dev directory, but I think
those should be auto-created on boot if they are needed.

Further suggestions? A trip to Frys later today, perhaps?

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 09:09 AM 4/7/2005 -0500, James Miller wrote:
>On Wed, 6 Apr 2005, James Miller wrote:
>
>>range) or to disable ttyS1 (COM 2 as the BIOS sees it, I believe) and see
>>if that relieves any potential IRQ 3 conflict.
>
>I tried disabling COM 2 in the BIOS (set it to "off" there). When I look
>at dmesg output, it does, indeed, appear to be off and is not getting
>assigned an IRQ by Linux. I see in dmesg output only ttyS0, assigned IRQ
>4. So it seems I have succeeded in freeing up IRQ 3 and resolving any
>potential conflict over it that might be contributing to sound issues.
>Nonetheless, the sound is of the same poor quality when I try to play
>files stored on the hard drive with mp3blaster. It is scratchy and I get
>pauses when some other computer activity occurs, just like before. I
>therefore presume that IRQ conflicts are not the operative problem here.
>
>I see no io address associated with the sound module(s) in cat
>/proc/ioports output, so that could be part of my problem. I also do not
>see IRQ 5 associated with anything (or even listed) in cat
>/proc/interrupts output, though I've tried to associate the pas2 module
>with it by specifying sb_irq=5 (among other parameters) in /etc/modules. I
>don't see the device files Ray mentioned as being used by Soundblaster
>emulation (/dev/dsp1 or /dev/audio1) in the /dev directory, but I think
>those should be auto-created on boot if they are needed.
>
>Further suggestions? A trip to Frys later today, perhaps?


Before you spend your money ... surely a trip to Fry's would be expensive
for someone in the CDT time zone ... I'd suggest one more try, possibly
one a bit more systematic than what you've been doing. (I'm seeing some
gaps in your testing, and I can't tell if you really are skipping steps or
just being terse in your reports to us.)

1. Set up the /etc/modules entry for the driver so it had both the regular
and the sb_* entries. Of course, make sure the sb_* entries match the ones
you set the card to using the DOS program.

2. Create the device entries if they are not present. (I was a bit
surprised that they are not present, but if they are not, you are wrong
that they "should be auto-created on boot if they are needed" ... well,
maybe not wrong about "should*, but should != are, and in fact they are
not.) Use mknod to create them by hand. (BTW, is /dev/dsp or /dev/dsp0
present? If not, you may be using devfs, and that puts the devices
somewhere different ... I forget where since I don't use it, but maybe
/dev/sound/dsp1 and so on. If /dev/dsp is present, see if it is s symlink
to something other than /dev/dsp0 ... this might help you track down dsp1.)
The relevant values for creating dsp1 are major 14, minor 19 (man mknod
will explain this). Also make sure the userid you are using for testing has
permission to write to this device ... making its permissions match
/dev/dsp will probably suffice.

3. Try one of the programs I suggested with the output directed to the
appropriate dsp1 entry (which depends on where you find it, or put it, in
step 2).

If sound still does not work, include in your report:

A. The EXACT entry from /etc/modules .

B. ALL dmesg output related to sound.

C. Relevant parts of /proc/interrupts and /proc/ioports from AFTER step 3.
(Interrupts don't show up until they are accessed.)

D. The EXACT line you used in running the music program you test with.

E. Any STDOUT or STDERR output from the test music program (like you did
before).

F. The output of "ls -l /dev/dsp*" (or the equivalent if you are using devfs).

As I said, you may already have done all of this carefully and correctly. I
just can't tell from the messages you posted if this is the case, or if you
might have skipped a step in the tests. (Well, it is clear that the absence
of /dev/dsp1 is a problem, whatever else is going on.)

One last detail -- you say you are testing with this command:

me@mymachine:~/MyMusic$ sudo mpg123 -a /dev/audio1 03\ -\ Norman\ Blake\ \
\ You\ Are\ My\ Sunshine.ogg

Last time I checked, mpg123 does not play ogg files. You need to match the
app to the file type ... use ogg123 with *.ogg files, mpg123 with *.mp3
files. This is not the cause of the problem you report though ... most
likely that is the absence of /dev/dsp1 .


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005, Ray Olszewski wrote:

> bit more systematic than what you've been doing. (I'm seeing some gaps in
> your testing, and I can't tell if you really are skipping steps or just being
> terse in your reports to us.)

I'd call what I'm doing semi-controlled, semi-informed flailing. I know
some basic troubleshooting techniques and I've adapted them from other
realms to computers (actually refined them somewhat using computers). But
I don't understand very thoroughly alot of what the computer is doing or
Linux's role, so it's somewhat arbitrary. I'm not trained in any sort of
formal way with computers--never used one prior to age 30--so approaching
these things systematically is not my initial reaction.

Anyway, I'll try what you've suggested. But one aspect needs some further
comment and clarification, namely:

> 2. Create the device entries if they are not present. (I was a bit surprised
> that they are not present, but if they are not, you are wrong that they
> "should be auto-created on boot if they are needed" ... well, maybe not wrong
> about "should*, but should != are, and in fact they are not.) Use mknod to
> create them by hand. (BTW, is /dev/dsp or /dev/dsp0 present? If not, you may
> be using devfs, and that puts the devices somewhere different ... I forget
> where since I don't use it, but maybe /dev/sound/dsp1 and so on. If /dev/dsp
> is present, see if it is s symlink to something other than /dev/dsp0 ... this
> might help you track down dsp1.) The relevant values for creating dsp1 are
> major 14, minor 19 (man mknod will explain this). Also make sure the userid
> you are using for testing has permission to write to this device ... making
> its permissions match /dev/dsp will probably suffice.

I think we're on udev here, Ray. This system was just installed (couple of
weeks ago) using a netinst image (testing) and immediately switched over
to unstable. Things like devfs and udev evoke fits of dyslexia in me.
Maybe I can overcome the miscombobulation somewhat in this discussion.

Upon further inspection, here's what I've found. First, /dev/dsp doesn't
appear to be a symlink. Second, I have a sub directory under /dev called
..udevdb, which is one of my indications that the system is using udev.
Under /dev I have dsp and dspW. I also see audio there. No audio1 or
dsp1--or dsp0 for that matter. Then, there is a sub directory called
..static. Under .static there is also a sub directory dev, and under this
one there is, in fact, a dsp, dsp1, dsp2, dsp3 and audio, audio1, audio2
and audio3. I didn't see these previously. I've just tried outputting
sound to dsp1 and audio1 there using your ogg123 example, but received the
same oss error I posted about last night.

So, given that udev seems to be in play here, and that dsp1 and audio1
exist on the system under /dev/.static/dev, how do you recommend I
proceed? Is my test attempting to output that .ogg file to
/dev/.static/dev/dsp1 and /dev/.static/dev/audio1 valid (other things
being equal)?

Once I get some more feedback on this, I'll proceed with the further
testing you suggest.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 12:31 PM 4/7/2005 -0500, James Miller wrote:
[...]
>Anyway, I'll try what you've suggested. But one aspect needs some further
>comment and clarification, namely:
>
>>2. Create the device entries if they are not present. (I was a bit
>>surprised that they are not present, but if they are not, you are wrong
>>that they "should be auto-created on boot if they are needed" ... well,
>>maybe not wrong about "should*, but should != are, and in fact they are
>>not.) Use mknod to create them by hand. (BTW, is /dev/dsp or /dev/dsp0
>>present? If not, you may be using devfs, and that puts the devices
>>somewhere different ... I forget where since I don't use it, but maybe
>>/dev/sound/dsp1 and so on. If /dev/dsp is present, see if it is s symlink
>>to something other than /dev/dsp0 ... this might help you track down
>>dsp1.) The relevant values for creating dsp1 are major 14, minor 19 (man
>>mknod will explain this). Also make sure the userid you are using for
>>testing has permission to write to this device ... making its permissions
>>match /dev/dsp will probably suffice.
>
>I think we're on udev here, Ray. This system was just installed (couple of
>weeks ago) using a netinst image (testing) and immediately switched over
>to unstable. Things like devfs and udev evoke fits of dyslexia in me.
>Maybe I can overcome the miscombobulation somewhat in this discussion.
>
>Upon further inspection, here's what I've found. First, /dev/dsp doesn't
>appear to be a symlink. Second, I have a sub directory under /dev called
>.udevdb, which is one of my indications that the system is using udev.
>Under /dev I have dsp and dspW. I also see audio there. No audio1 or
>dsp1--or dsp0 for that matter. Then, there is a sub directory called
>.static. Under .static there is also a sub directory dev, and under this
>one there is, in fact, a dsp, dsp1, dsp2, dsp3 and audio, audio1, audio2
>and audio3. I didn't see these previously. I've just tried outputting
>sound to dsp1 and audio1 there using your ogg123 example, but received the
>same oss error I posted about last night.
>
>So, given that udev seems to be in play here, and that dsp1 and audio1
>exist on the system under /dev/.static/dev, how do you recommend I
>proceed? Is my test attempting to output that .ogg file to
>/dev/.static/dev/dsp1 and /dev/.static/dev/audio1 valid (other things
>being equal)?
>
>Once I get some more feedback on this, I'll proceed with the further
>testing you suggest.

To get really good help here, you need to hear from someone who is using
udev. I'm not ... I still use 2.4.x kernels on everything I run ... so I am
not familiar with the details of this mechanism for making dynamic nodes.
But I would guess that the devices you found in /dev/.static/dev are the
ones of interest ... once you report the details on them that Iasked for in
my prior message, I'll feel more confident of that belief.

At this point, my best suggestion is to follow the step-by-step procedure I
described in my prior message, using /dev/.static/dev/dsp1 (or audio1) as
the target device. Once I see the full report of the test, as I outlined it
in my prior message, I (and others) should be able to indicate if there is
an error of detail in your procedure or if the sound driver just does not
work the way I think it does.

PS, -- In addition to what I asked for before, please include the EXACT
output of both "ls -l /dev/dsp*" -AND- "ls -l /dev/.static/dev/dsp*".

PPS -- Part of my intent in outlining a test procedure was to get all the
results in one place, all in the same message. So please do quote them when
you do the test ... don't just say they were the same as before.


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

I'll start the testing responses to this, your most recent, posting, and
move to your previous posting after this one. I wanted to ask about udev
before running the tests in your previous post on the assumption that its
presence might change something fundamental in testing procedures. The
tests I ran where I "got the same responses as before" were preliminary
explorations to find out if that might be the case, and were not intended
to be the responses you asked for earlier.

On Thu, 7 Apr 2005, Ray Olszewski wrote:

> At this point, my best suggestion is to follow the step-by-step procedure I
> described in my prior message, using /dev/.static/dev/dsp1 (or audio1) as the
> target device. Once I see the full report of the test, as I outlined it in my
> prior message, I (and others) should be able to indicate if there is an error
> of detail in your procedure or if the sound driver just does not work the way
> I think it does.

Here is the output when I try the /dev/.static/dev directories using
123ogg:

me@mymachine:~/MyMusic$ sudo ogg123 -d oss -o dsp:/dev/.static/dev/dsp1
03\ -\ Norman\ Blake\ \ \ You\ Are\ My\ Sunshine.ogg

Audio Device: OSS audio driver output

Playing: 03 - Norman Blake You Are My Sunshine.ogg
Ogg Vorbis stream: 2 channel, 44100 Hz
Title: Norman Blake / You Are My Sunshine
Artist: Various
Track number: 3
Tracktotal: 19
Album: O Brother, Where Art Thou?
Comment: Ripped with Sound Juicer
Error: Cannot open device oss.

me@mymachine:~/MyMusic$ sudo ogg123 -d oss -o dsp:/dev/.static/dev/audio1
03\ -\ Norman\ Blake\ \ \ You\ Are\ My\ Sunshine.ogg

Audio Device: OSS audio driver output

Playing: 03 - Norman Blake You Are My Sunshine.ogg
Ogg Vorbis stream: 2 channel, 44100 Hz
Title: Norman Blake / You Are My Sunshine
Artist: Various
Track number: 3
Tracktotal: 19
Album: O Brother, Where Art Thou?
Comment: Ripped with Sound Juicer
Error: Cannot open device oss.

me@mymachine:~/MyMusic$

> PS, -- In addition to what I asked for before, please include the EXACT
> output of both "ls -l /dev/dsp*" -AND- "ls -l /dev/.static/dev/dsp*".

me@mymachine:~$ ls -l /dev/dsp*
crw-rw---- 1 root audio 14, 3 2005-04-07 08:44 /dev/dsp
crw-rw---- 1 root audio 14, 5 2005-04-07 08:44 /dev/dspW
me@mymachine:~$

me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp*
ls: /dev/.static/dev/dsp*: No such file or directory
me@mymachine:~$

On the other hand, when I eliminate the wildcard and use real numbers I
get:

me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp1
crw-rw---- 1 root audio 14, 19 2004-09-18 06:52 /dev/.static/dev/dsp1
me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp2
crw-rw---- 1 root audio 14, 35 2004-09-18 06:52 /dev/.static/dev/dsp2
me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp3
crw-rw---- 1 root audio 14, 51 2004-09-18 06:52 /dev/.static/dev/dsp3
me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp4
ls: /dev/.static/dev/dsp4: No such file or directory
me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp
crw-rw---- 1 root audio 14, 3 2004-09-18 06:52 /dev/.static/dev/dsp
me@mymachine:~$

Your guess is as good as mine as to why wildcards don't work here.
Actually, your guess is probably better than mine :)

> 2. Create the device entries if they are not present. (I was a bit surprised
> that they are not present, but if they are not, you are wrong that they
> "should be auto-created on boot if they are needed" ... well, maybe not wrong
> about "should*, but should != are, and in fact they are not.) Use mknod to
> create them by hand. (BTW, is /dev/dsp or /dev/dsp0 present? If not, you may
> be using devfs, and that puts the devices somewhere different ... I forget
> where since I don't use it, but maybe /dev/sound/dsp1 and so on. If /dev/dsp
> is present, see if it is s symlink to something other than /dev/dsp0 ... this
> might help you track down dsp1.) The relevant values for creating dsp1 are
> major 14, minor 19 (man mknod will explain this). Also make sure the userid
> you are using for testing has permission to write to this device ... making
> its permissions match /dev/dsp will probably suffice.

Skipped since I'm not sure if these nodes need to be created and/or
copied, and I'm not sure if you're sure either. Or whether this step may
be invalidated by the presence of udev. Corrections welcome.

> 3. Try one of the programs I suggested with the output directed to the
> appropriate dsp1 entry (which depends on where you find it, or put it, in
> step 2).

The output from trying to use /dev/.static/dev/dsp1 and
/dev/.static/dev/audio1 above suffices, I presume?

> If sound still does not work, include in your report:
>
> A. The EXACT entry from /etc/modules .

me@mymachine:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file should contain the names of kernel modules that are
# to be loaded at boot time, one per line. Comments begin with
# a "#", and everything on the line after them are ignored.
# pas2 io=220 irq=7 dma=1
# sb io=0x230 irq=5 dma=1 mpu_io=0x330

ide-cd
ide-detect
sd_mod
pas2 io=0x388 irq=3 dma=5 sb_io=0x230 sb_irq=5 sb_dma=1
opl3 io=0x388
me@mymachine:~$

> B. ALL dmesg output related to sound.

I'll try, presuming I can identify what's relevant:

me@mymachine:~$ dmesg |more

isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize

hdd: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Pro Audio Spectrum driver Copyright (C) by Hannu Savolainen 1993-1996
YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft
1993-1996
Capability LSM initialized
kjournald starting. Commit interval 5 seconds

[drm] Initialized sis 1.1.0 20030826 on minor 0: Silicon Integrated
Systems [SiS] 300/305 PCI/AGP VGA Display Adapter
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
Sound: DMA (output) timed out - IRQ/DRQ config error?
me@mymachine:~$

> C. Relevant parts of /proc/interrupts and /proc/ioports from AFTER step 3.
> (Interrupts don't show up until they are accessed.)

me@mymachine:~$ cat /proc/interrupts
CPU0
0: 17539757 XT-PIC timer
1: 33620 XT-PIC i8042
2: 0 XT-PIC cascade
3: 2244 XT-PIC PAS16
7: 1 XT-PIC parport0
8: 1 XT-PIC rtc
10: 8647 XT-PIC eth0
11: 192875 XT-PIC uhci_hcd
12: 44880 XT-PIC i8042
14: 18338 XT-PIC ide0
15: 35222 XT-PIC ide1
NMI: 0
LOC: 0
ERR: 0
MIS: 0
me@mymachine:~$

me@mymachine:~$ cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
0388-038b : Yamaha OPL3
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0778-077a : parport0
0800-083f : 0000:00:07.3
0800-083f : pnp 00:00
0840-085f : 0000:00:07.3
0850-085f : pnp 00:00
0850-0857 : piix4-smbus
0cf8-0cff : PCI conf1
d880-d8ff : 0000:00:0e.0
dc00-dc7f : 0000:00:0d.0
dc00-dc7f : 0000:00:0d.0
dce0-dcff : 0000:00:07.2
dce0-dcff : uhci_hcd
e000-efff : PCI Bus #01
ec00-ecff : 0000:01:00.0
ffa0-ffaf : 0000:00:07.1
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
me@mymachine:~$

Hey, why are ide0 and parport0 showing up thrice? Note that no address in
the 200 range are showing up.

> D. The EXACT line you used in running the music program you test with.

See my first answer above. Does it suffice? Copied right from the terminal
where I ran it.

> E. Any STDOUT or STDERR output from the test music program (like you did
> before).

I think it's there with the command, right?

> F. The output of "ls -l /dev/dsp*" (or the equivalent if you are using
> devfs).

See above.

> One last detail -- you say you are testing with this command:
>
> me@mymachine:~/MyMusic$ sudo mpg123 -a /dev/audio1 03\ -\ Norman\ Blake\ \ \
> You\ Are\ My\ Sunshine.ogg
>
> Last time I checked, mpg123 does not play ogg files. You need to match the
> app to the file type ... use ogg123 with *.ogg files, mpg123 with *.mp3
> files. This is not the cause of the problem you report though ... most likely
> that is the absence of /dev/dsp1 .

Ok. Registered. I never used mpg123 before and was expecting it to give me
some indication if I sent it the wrong kind of file.

James

PS Miscellaneous observations: the opl3 module will assign itself to io
0x388 while the pas2 module will not--regardless of the presence or
absence of the opl3 driver with its io parameter (tried it both with and
without). The kernel doc seemed to assign pas2 and opl3 (where needed, and
I'm not sure I need it: seems to make no difference in sound output
whether it's there or not) the same io unabashedly, so I did the same.
Assigning the pas2 module to io 0x230 made no difference in sound
characteristics that I could observe--whether or not a sb_io=0x230 was
present or absent. And the io still didn't show up in cat /proc/ioports
output in any case. Leaving the io paramter absent from the pas2 line
results in an error message, as follows:
Mar 28 20:57:29 localhost kernel: Pro Audio Spectrum driver Copyright (C)
by Hannu Savolainen 1993-1996 Mar
28 20:57:29 localhost kernel: I/O, IRQ, DMA and type are mandatory
--regardless of whether I've specified sb_io= or not on that
same line.

PPS Whew! I should get an honorary geek doctorate for this, a good
citizenship award, or at least be taught the secret handshake of the Geek
International Cadre. How 'bout it, Ray?
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Wed, 6 Apr 2005, James Miller wrote:

> On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:
>
>> Can you post your /proc/interrupts here ?
>
> me@mymachine:~$ cat /proc/interrupts
> CPU0
> 0: 25759543 XT-PIC timer
> 1: 23960 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 3: 5223 XT-PIC PAS16
> 7: 1 XT-PIC parport0
> 8: 1 XT-PIC rtc
> 10: 50736 XT-PIC eth0
> 11: 283557 XT-PIC uhci_hcd
> 12: 51870 XT-PIC i8042
> 14: 29656 XT-PIC ide0
> 15: 493057 XT-PIC ide1
> NMI: 0
> LOC: 0
> ERR: 0
> MIS: 0
> me@mymachine:~$
>

interrupt 5 is not used, nor is 9

>> Also if your soundcard is an ISA one and your BIOS allow you, you can play
>> with the way BIOS assign IRQ to devices (ISA/PCI or PCI) but this could be
>> a dangerous thing if you don't know what you are doing.
>> On a normal system interrupts 0, 1, 2, 3, 4, 7 are normally assigned to
>> ISA devices and 14 and 15 to PCI IDE. The rest of them depends of the
>> configuration of the machine.
>> I usually saw that IRQ 5 or IRQ 9 was used by older soundcards.
>
> ISA soundcard, yes. Like I said earlier in this thread the BIOS is reported
> as PnP by Linux. Very limited tweaking there--certainly nothing as advanced
> as setting IRQ's. I'm afraid my only options are to either set a different
> IRQ on the soundcard using the DOS software (though I see no free IRQ's in
> range) or to disable ttyS1 (COM 2 as the BIOS sees it, I believe) and see if
> that relieves any potential IRQ 3 conflict. Possible IRQ's for the card are:
> 2, 3, 5, 7, 10, 11, 12, 15 for "Soundman" and 2, 3, 5, and 7 for "Sound
> blaster."
>

i think you can use interrupt 5 or 9 if there's a way to set it

> James
> -
>

--
?


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005 caszonyi@rdslink.ro wrote:

> On Wed, 6 Apr 2005, James Miller wrote:
>
>> if that relieves any potential IRQ 3 conflict. Possible IRQ's for the card
>> are: 2, 3, 5, 7, 10, 11, 12, 15 for "Soundman" and 2, 3, 5, and 7 for
>> "Sound blaster."
>
> i think you can use interrupt 5 or 9 if there's a way to set it

As listed above, I gather from the documentation that comes with the card
that I cannot set it to use IRQ 9. IRQ 5 is assigned to sb_irq
(Soundblaster emulation, if you've been following). Why it doesn't show up
in the output I sent I can't say, but I've certainly specified sb_irq=5 in
the relevant module line in /etc/modules. I do have the option of swapping
Soundman (3) and Soundblaster (5) IRQ's, I suppose, to see if that makes
any difference. Haven't tried that yet.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

On Thu, 7 Apr 2005, James Miller wrote:

> module line in /etc/modules. I do have the option of swapping Soundman (3)
> and Soundblaster (5) IRQ's, I suppose, to see if that makes any difference.
> Haven't tried that yet.

Just tried it (made Soundman IRQ 5 and Soundblaster 3 and edited
/etc/modules accordingly). Doesn't make any difference. Same scratchy,
skipping sound.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: sound problems on Debian unstable

At 02:11 PM 4/7/2005 -0500, James Miller wrote:
>I'll start the testing responses to this, your most recent, posting, and
>move to your previous posting after this one. I wanted to ask about udev
>before running the tests in your previous post on the assumption that its
>presence might change something fundamental in testing procedures. The
>tests I ran where I "got the same responses as before" were preliminary
>explorations to find out if that might be the case, and were not intended
>to be the responses you asked for earlier.

Right. I just wanted to save a round later, in case I hadn't been clear on
this point.

Overall comment: The only real possibility of error I see in what you did
is misspecification of the SB ioport. If that isn't wrong, I have nothing
to suggest based on this report ... I'm probably misunderstanding how the
driver works. Sorry. Go to Fry's, I guess.

>On Thu, 7 Apr 2005, Ray Olszewski wrote:
>
>>At this point, my best suggestion is to follow the step-by-step procedure
>>I described in my prior message, using /dev/.static/dev/dsp1 (or audio1)
>>as the target device. Once I see the full report of the test, as I
>>outlined it in my prior message, I (and others) should be able to
>>indicate if there is an error of detail in your procedure or if the sound
>>driver just does not work the way I think it does.
>
>Here is the output when I try the /dev/.static/dev directories using 123ogg:
>
>me@mymachine:~/MyMusic$ sudo ogg123 -d oss -o dsp:/dev/.static/dev/dsp1
>03\ -\ Norman\ Blake\ \ \ You\ Are\ My\ Sunshine.ogg
>
>Audio Device: OSS audio driver output
>
>Playing: 03 - Norman Blake You Are My Sunshine.ogg
>Ogg Vorbis stream: 2 channel, 44100 Hz
>Title: Norman Blake / You Are My Sunshine
>Artist: Various
>Track number: 3
>Tracktotal: 19
>Album: O Brother, Where Art Thou?
>Comment: Ripped with Sound Juicer
>Error: Cannot open device oss.
>
>me@mymachine:~/MyMusic$ sudo ogg123 -d oss -o dsp:/dev/.static/dev/audio1
>03\ -\ Norman\ Blake\ \ \ You\ Are\ My\ Sunshine.ogg
>
>Audio Device: OSS audio driver output
>
>Playing: 03 - Norman Blake You Are My Sunshine.ogg
>Ogg Vorbis stream: 2 channel, 44100 Hz
>Title: Norman Blake / You Are My Sunshine
>Artist: Various
>Track number: 3
>Tracktotal: 19
>Album: O Brother, Where Art Thou?
>Comment: Ripped with Sound Juicer
>Error: Cannot open device oss.

OK. In context, this error means ogg123 cannot open (for example)
dsp:/dev/.static/dev/audio1 ... either there is no physical device
associated with the logical device or you don't have permission to open it.
(I tested this here to be sure.)

>me@mymachine:~/MyMusic$
>
>>PS, -- In addition to what I asked for before, please include the EXACT
>>output of both "ls -l /dev/dsp*" -AND- "ls -l /dev/.static/dev/dsp*".
>
>me@mymachine:~$ ls -l /dev/dsp*
>crw-rw---- 1 root audio 14, 3 2005-04-07 08:44 /dev/dsp
>crw-rw---- 1 root audio 14, 5 2005-04-07 08:44 /dev/dspW
>me@mymachine:~$
>
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp*
>ls: /dev/.static/dev/dsp*: No such file or directory
>me@mymachine:~$
>
>On the other hand, when I eliminate the wildcard and use real numbers I get:
>
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp1
>crw-rw---- 1 root audio 14, 19 2004-09-18 06:52 /dev/.static/dev/dsp1
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp2
>crw-rw---- 1 root audio 14, 35 2004-09-18 06:52 /dev/.static/dev/dsp2
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp3
>crw-rw---- 1 root audio 14, 51 2004-09-18 06:52 /dev/.static/dev/dsp3
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp4
>ls: /dev/.static/dev/dsp4: No such file or directory
>me@mymachine:~$ sudo ls -l /dev/.static/dev/dsp
>crw-rw---- 1 root audio 14, 3 2004-09-18 06:52 /dev/.static/dev/dsp
>me@mymachine:~$
>
>Your guess is as good as mine as to why wildcards don't work here.
>Actually, your guess is probably better than mine :)

OK. This part looks OK. dsp1 has the right major and minor numbers.
Assuming sudo works to give you permission to write to this device ... I
normally do this by adding the userid I'm using to group audio (in
/etc/group) ... this is not the source of your problem. If it works to
access /dev/dsp, it is probably OK here too.

The "ls" problem bothers me a little bit. It probably means ls cannot read
the directory /dev/.static/dev to expand the wildcard. Just a guess, though.

It's a longshot, but you might try creating the node /dev/dsp1 just as a
test ("mknod /dev/dsp1 c 14 19"; "chmod 660 /dev/dsp1"; "chgrp audio
/dev/dsp1" -- then check that it looks like this in ls -l: "crw-rw---- 1
root audio 14, 19 Jun 13 2001 /dev/dsp1") and now see if ogg123 can open
it. It's a long shot, though.

>>2. Create the device entries if they are not present. (I was a bit
>>surprised that they are not present, but if they are not, you are wrong
>>that they "should be auto-created on boot if they are needed" ... well,
>>maybe not wrong about "should*, but should != are, and in fact they are
>>not.) Use mknod to create them by hand. (BTW, is /dev/dsp or /dev/dsp0
>>present? If not, you may be using devfs, and that puts the devices
>>somewhere different ... I forget where since I don't use it, but maybe
>>/dev/sound/dsp1 and so on. If /dev/dsp is present, see if it is s symlink
>>to something other than /dev/dsp0 ... this might help you track down
>>dsp1.) The relevant values for creating dsp1 are major 14, minor 19 (man
>>mknod will explain this). Also make sure the userid you are using for
>>testing has permission to write to this device ... making its permissions
>>match /dev/dsp will probably suffice.
>
>Skipped since I'm not sure if these nodes need to be created and/or
>copied, and I'm not sure if you're sure either. Or whether this step may
>be invalidated by the presence of udev. Corrections welcome.

Probably OK, as I said above.

>>3. Try one of the programs I suggested with the output directed to the
>>appropriate dsp1 entry (which depends on where you find it, or put it, in
>>step 2).
>
>The output from trying to use /dev/.static/dev/dsp1 and
>/dev/.static/dev/audio1 above suffices, I presume?
>
>>If sound still does not work, include in your report:
>>
>>A. The EXACT entry from /etc/modules .
>
>me@mymachine:~$ cat /etc/modules
># /etc/modules: kernel modules to load at boot time.
>#
># This file should contain the names of kernel modules that are
># to be loaded at boot time, one per line. Comments begin with
># a "#", and everything on the line after them are ignored.
># pas2 io=220 irq=7 dma=1
># sb io=0x230 irq=5 dma=1 mpu_io=0x330
>
>ide-cd
>ide-detect
>sd_mod
>pas2 io=0x388 irq=3 dma=5 sb_io=0x230 sb_irq=5 sb_dma=1
>opl3 io=0x388
>me@mymachine:~$

Is 0x230 the right ioport? I thought you said in an earlier message that
you'd moved the SB emulation to 0x220 (but I don't have the old messages to
check). Did you move it back? Or is my memory failing?

I do recall that sb_irq= 5 is right. I don't remember what you did about
sb_dma.

>>B. ALL dmesg output related to sound.
>
>I'll try, presuming I can identify what's relevant:
>
>me@mymachine:~$ dmesg |more
>
>isapnp: Scanning for PnP cards...
>isapnp: No Plug & Play device found
>serio: i8042 AUX port at 0x60,0x64 irq 12
>serio: i8042 KBD port at 0x60,0x64 irq 1
>Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
>io scheduler noop registered
>io scheduler anticipatory registered
>io scheduler deadline registered
>io scheduler cfq registered
>RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
>
>hdd: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
>Uniform CD-ROM driver Revision: 3.20
>Pro Audio Spectrum driver Copyright (C) by Hannu Savolainen 1993-1996
>YM3812 and OPL-3 driver Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996
>Capability LSM initialized
>kjournald starting. Commit interval 5 seconds
>
>[drm] Initialized sis 1.1.0 20030826 on minor 0: Silicon Integrated
>Systems [SiS] 300/305 PCI/AGP VGA Display Adapter
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?
>Sound: DMA (output) timed out - IRQ/DRQ config error?

This may indicate a mismatch between the card's hardware settings and the
values in /etc/modules. Especially if you get these messages only when you
try to specify sb_* values.

>me@mymachine:~$
>
>>C. Relevant parts of /proc/interrupts and /proc/ioports from AFTER step
>>3. (Interrupts don't show up until they are accessed.)
>
>me@mymachine:~$ cat /proc/interrupts
> CPU0
> 0: 17539757 XT-PIC timer
> 1: 33620 XT-PIC i8042
> 2: 0 XT-PIC cascade
> 3: 2244 XT-PIC PAS16
> 7: 1 XT-PIC parport0
> 8: 1 XT-PIC rtc
> 10: 8647 XT-PIC eth0
> 11: 192875 XT-PIC uhci_hcd
> 12: 44880 XT-PIC i8042
> 14: 18338 XT-PIC ide0
> 15: 35222 XT-PIC ide1
>NMI: 0
>LOC: 0
>ERR: 0
>MIS: 0
>me@mymachine:~$
>
>me@mymachine:~$ cat /proc/ioports
>0000-001f : dma1
>0020-0021 : pic1
>0040-0043 : timer0
>0050-0053 : timer1
>0060-006f : keyboard
>0070-0077 : rtc
>0080-008f : dma page reg
>00a0-00a1 : pic2
>00c0-00df : dma2
>00f0-00ff : fpu
>0170-0177 : ide1
>01f0-01f7 : ide0
>0376-0376 : ide1
>0378-037a : parport0
>037b-037f : parport0
>0388-038b : Yamaha OPL3
>03c0-03df : vga+
>03f6-03f6 : ide0
>03f8-03ff : serial
>0778-077a : parport0
>0800-083f : 0000:00:07.3
> 0800-083f : pnp 00:00
>0840-085f : 0000:00:07.3
> 0850-085f : pnp 00:00
> 0850-0857 : piix4-smbus
>0cf8-0cff : PCI conf1
>d880-d8ff : 0000:00:0e.0
>dc00-dc7f : 0000:00:0d.0
> dc00-dc7f : 0000:00:0d.0
>dce0-dcff : 0000:00:07.2
> dce0-dcff : uhci_hcd
>e000-efff : PCI Bus #01
> ec00-ecff : 0000:01:00.0
>ffa0-ffaf : 0000:00:07.1
> ffa0-ffa7 : ide0
> ffa8-ffaf : ide1
>me@mymachine:~$
>
>Hey, why are ide0 and parport0 showing up thrice? Note that no address in
>the 200 range are showing up.
>
>>D. The EXACT line you used in running the music program you test with.
>
>See my first answer above. Does it suffice? Copied right from the terminal
>where I ran it.
>
>>E. Any STDOUT or STDERR output from the test music program (like you did
>>before).
>
>I think it's there with the command, right?
>
>>F. The output of "ls -l /dev/dsp*" (or the equivalent if you are using
>>devfs).
>
>See above.

The response above does cover all 3 of these.

>>One last detail -- you say you are testing with this command:
>>
>>me@mymachine:~/MyMusic$ sudo mpg123 -a /dev/audio1 03\ -\ Norman\ Blake\
>>\ \ You\ Are\ My\ Sunshine.ogg
>>
>>Last time I checked, mpg123 does not play ogg files. You need to match
>>the app to the file type ... use ogg123 with *.ogg files, mpg123 with
>>*.mp3 files. This is not the cause of the problem you report though ...
>>most likely that is the absence of /dev/dsp1 .
>
>Ok. Registered. I never used mpg123 before and was expecting it to give me
>some indication if I sent it the wrong kind of file.

In your tests, mpg123 never got around to attempting to play the file (and
Linux apps in general don't pay attention to extensions), so mpg123 never
"noticed" that it wasn't in mp3 format. For example:

ray@flagg:~$ mpg123
/home/music/ogg/Bob_Seger_\&_The_Silver_Bullet_Band/Live_Bul let/Katmandu.ogg
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3.
Version 0.59r (1999/Jun/15). Written and copyrights by Michael
Hipp.
Uses code from various people. See 'README' for more!
THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK!

Directory:
/home/music/ogg/Bob_Seger_&_The_Silver_Bullet_Band/Live_Bull et/
Playing MPEG stream from Katmandu.ogg ...
Junk at the beginning 4f676753
Free format not supported: (head ffff0703)
Junk at the beginning 766f7262
MPEG 1.0 layer I, 320 kbit/s, 48000 Hz dual-channel
Illegal Audio-MPEG-Header 0x7017380c at offset 0x1709.
Skipped 3152148 bytes in input.
Illegal Audio-MPEG-Header 0xcb0ff566 at offset 0x30315d.

Of course, we folks who never make mistakes normally don't get to see the
error messages, so how would we know what they say?

>James
>
>PS Miscellaneous observations: the opl3 module will assign itself to io
>0x388 while the pas2 module will not--regardless of the presence or
>absence of the opl3 driver with its io parameter (tried it both with and
>without). The kernel doc seemed to assign pas2 and opl3 (where needed, and
>I'm not sure I need it: seems to make no difference in sound output
>whether it's there or not) the same io unabashedly, so I did the same.
>Assigning the pas2 module to io 0x230 made no difference in sound
>characteristics that I could observe--whether or not a sb_io=0x230 was
>present or absent. And the io still didn't show up in cat /proc/ioports
>output in any case. Leaving the io paramter absent from the pas2 line
>results in an error message, as follows:
>Mar 28 20:57:29 localhost kernel: Pro Audio Spectrum driver Copyright (C)
>by Hannu Savolainen 1993-1996 Mar 28 20:57:29 localhost kernel: I/O, IRQ,
>DMA and type are mandatory
>--regardless of whether I've specified sb_io= or not on that same line.
>
>PPS Whew! I should get an honorary geek doctorate for this, a good
>citizenship award, or at least be taught the secret handshake of the Geek
>International Cadre. How 'bout it, Ray?

Shhh. There is no secret Geek International Cadre, let alone a secret
handshake. Nothing to see here folks ... move along. And pay no attention
to the man behind that curtain ....


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs