7:46 a.m.
I read but did not understand any details of udev but I am certain it
is why my old application called gmfsk finds that /dev/dsp is busy. It
is not busy but the current setup of udev makes it appear busy. Also it
is certain that udev can have upset with the new kernels and be causing
the problems some or most of us are having.
Udev is not simple.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
7:52 a.m.
Somebody in the thread at some point said:
I read but did not understand any details of udev but I am
certain
it is why my old application called gmfsk finds that /dev/dsp is busy.
It is not busy but the current setup of udev makes it appear busy. Also
it is certain that udev can have upset with the new kernels and be
causing the problems some or most of us are having.
What makes you think /dev/dsp isn't busy, and if it is busy, that udev
is to blame? Try this
lsof -n | grep /dev/dsp
it should list any processes that have /dev/dsp open.
-Andy
9:21 a.m.
Andy Green wrote:
Somebody in the thread at some point said:
> I read but did not understand any details of udev but I am certain
> it is why my old application called gmfsk finds that /dev/dsp is busy.
> It is not busy but the current setup of udev makes it appear busy. Also
> it is certain that udev can have upset with the new kernels and be
> causing the problems some or most of us are having.
What makes you think /dev/dsp isn't busy, and if it is busy, that udev
is to blame? Try this
lsof -n | grep /dev/dsp
it should list any processes that have /dev/dsp open.
-Andy
I did that and got no result. I think that means it is not busy?
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
9:49 a.m.
Somebody in the thread at some point said:
Andy Green wrote:
> Somebody in the thread at some point said:
>
>> I read but did not understand any details of udev but I am certain
>> it is why my old application called gmfsk finds that /dev/dsp is busy.
>> It is not busy but the current setup of udev makes it appear busy. Also
>> it is certain that udev can have upset with the new kernels and be
>> causing the problems some or most of us are having.
>
> What makes you think /dev/dsp isn't busy, and if it is busy, that udev
> is to blame? Try this
>
> lsof -n | grep /dev/dsp
>
> it should list any processes that have /dev/dsp open.
>
> -Andy
>
I did that and got no result. I think that means it is not busy?
It means no other app has it open, maybe some other meaning of "busy" is
in mind.
I just looked at the sources in ./src/snd.c ... can you copy the last
couple of things it says before it fails? It should say something like
"Opening /dev/dsp for writing" or similar.
Another tool is strace, just run the thing as
strace gmfsk
add whatever gmfsk args you usually use at the end.
After it stops spewing nonsense, review the last few dozen lines looking
for lines referring to /dev/dsp, and cut and paste them here.
-Andy
9:53 a.m.
Another tool is strace, just run the thing as
strace gmfsk
add whatever gmfsk args you usually use at the end.
After it stops spewing nonsense, review the last few dozen lines looking
for lines referring to /dev/dsp, and cut and paste them here.
Or, to avoid having to search by hand, just run
strace gmfsk <your-args> | grep -A 10 -B 10 "/dev/dsp"
This will filter out any instance of /dev/dsp, printing the 10 lines
before and 10 after for good measure (10 of course can be tuned to what
ever you feel is appropriate) ...
Chris
12:46 p.m.
strace gmfsk <your-args> | grep -A 10 -B 10
"/dev/dsp"
Correction : Just discovered strace sends its output to stderr, so the above
won't work (the pipe command only takes stdout). One way around this is to
redirect stderr to stdout
strace gmfsk <your-args> 2>&1 | grep -A 10 -B 10 "/dev/dsp"
cheers Chris
p.s. if you don't have strace, just run 'yum install strace'
2:10 p.m.
Andy Green wrote:
Somebody in the thread at some point said:
> Andy Green wrote:
>> Somebody in the thread at some point said:
>>
>>> I read but did not understand any details of udev but I am certain
>>> it is why my old application called gmfsk finds that /dev/dsp is busy.
>>> It is not busy but the current setup of udev makes it appear busy. Also
>>> it is certain that udev can have upset with the new kernels and be
>>> causing the problems some or most of us are having.
>> What makes you think /dev/dsp isn't busy, and if it is busy, that udev
>> is to blame? Try this
>>
>> lsof -n | grep /dev/dsp
>>
>> it should list any processes that have /dev/dsp open.
>>
>> -Andy
>>
> I did that and got no result. I think that means it is not busy?
It means no other app has it open, maybe some other meaning of "busy" is
in mind.
I just looked at the sources in ./src/snd.c ... can you copy the last
couple of things it says before it fails? It should say something like
"Opening /dev/dsp for writing" or similar.
Another tool is strace, just run the thing as
strace gmfsk
add whatever gmfsk args you usually use at the end.
After it stops spewing nonsense, review the last few dozen lines looking
for lines referring to /dev/dsp, and cut and paste them here.
-Andy
Hi Andy I am not yet able to save strace output. I tried $ strace gmfsk
gm.txt but it put notin in the file. Will experiment. Attached is a
screenshot of the warning panel I get. More when I figure out how to get
it in a file.
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
2:18 p.m.
Hi Andy I am not yet able to save strace output. I tried $ strace gmfsk
> gm.txt but it put notin in the file. Will experiment. Attached is a
screenshot of the warning panel I get. More when I figure out how to get
it in a file.
strace sends its output to stderr not stdout
try
strace gmfsk 2> gm.txt
chris
2:20 p.m.
Somebody in the thread at some point said:
> After it stops spewing nonsense, review the last few dozen lines
looking
> for lines referring to /dev/dsp, and cut and paste them here.
Chris Jones pointed out, strace sends its output to stderr, so you need
an unusual form of the > redirection thing...
strace gmfsk 2>/tmp/dump
you can run that from a virtual console window as well.
BTW the screenshot text is truncated?
-Andy
2:30 p.m.
>>>> "AG" == Andy Green <andy(a)warmcat.com>
writes:
AG> Somebody in the thread at some point said:
>> After it stops spewing nonsense, review the last few dozen
lines
>> looking for lines referring to /dev/dsp, and cut and paste them
>> here.
AG> Chris Jones pointed out, strace sends its output to stderr, so you
AG> need an unusual form of the > redirection thing...
The -o option seems easier to me.
strace -o /tmp/dump
- J<
2:53 p.m.
Andy Green wrote:
Somebody in the thread at some point said:
>> strace -o /tmp/dump
> Oh, but so much less fun ;)
>
> Yes, looking at 'man strace' would have been sensible I guess...
It's true, but redirecting has the advantage that it works on everything
without having to learn per-app switches.
-Andy
I used strace -o gm.txt gmfsk | grep xxxx but the grep did not work but
I got the whole mess saved in gm.txt now. But Nigel had a better idea
and his works...
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
3:01 p.m.
I used strace -o gm.txt gmfsk | grep xxxx but the grep did not work
but
I got the whole mess saved in gm.txt now. But Nigel had a better idea
and his works...
Hmm, well in this case you are redirecting the strace output to file, so the
grep command has nothing to work from from the pipe. !
Either
strace -o gm.txt gmfsk
grep xxx gm.txt
or as I said in a previous post
strace gmfsk 2>&1 | grep xxx
here, the 2>&1 redirects the stderr to stdout, so it is then seen by the pipe
(|) and grep commands
Chris
2:54 p.m.
It's true, but redirecting has the advantage that it works on
everything
without having to learn per-app switches.
I must confess I do the same. For future info, this page lists the most common
redirections
http://tldp.org/LDP/abs/html/io-redirection.html
Chris
2:12 p.m.
Chris Jones wrote:
> I did that and got no result. I think that means it is not busy?
Is this at the same time as gmfsk claims to find it busy ?
Chris
Yes
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
11 a.m.
On Thursday 02 August 2007 16:21, Karl Larsen wrote:
Andy Green wrote:
> Somebody in the thread at some point said:
>> I read but did not understand any details of udev but I am certain
>> it is why my old application called gmfsk finds that /dev/dsp is busy.
>> It is not busy but the current setup of udev makes it appear busy. Also
>> it is certain that udev can have upset with the new kernels and be
>> causing the problems some or most of us are having.
>
> What makes you think /dev/dsp isn't busy, and if it is busy, that udev
> is to blame? Try this
>
> lsof -n | grep /dev/dsp
>
> it should list any processes that have /dev/dsp open.
>
> -Andy
I did that and got no result. I think that means it is not busy?
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
Hi Karl. Did you have the gmfsk ham radio app running when you tried the above
command? I seem to remember a while back that you said that rx was ok, but
you got the /dev/dsp problem when tx'ing.
It may be worth trying starting gmfsk with aoss. You need to install the
package alsa-oss, then launch the app as.
aoss gmfsk
That is if gmsfk is the command for launching it.
I've just looked at this on one of my 2 machines that does not have a
soundcard capable of multiple audio streams. I listen to Internet radio, and
start opera with, aoss opera. This way I can use other audio apps at the same
time. I ran /usr/sbin/lsof -n | grep /dev/dsp while listening to Internet
radio, and just got a return to the command prompt. Btw www.bbc.co.uk/radio4
uses the BBC radio player, that is using RealPlayer (an OSS app).
So next I close Opera, and open Firefox, which isn't started using "aoss".
Go
to www.bbc.co.uk/radio4, click on listen live, and re-run,
/usr/sbin/lsof -n | grep /dev/dsp
This time I get the following output.
$ /usr/sbin/lsof -n | grep /dev/dsp
realplay. 29809 djmons 5w CHR 14,3 360131 /dev/dsp
Now /dev/dsp is busy, and I know I can't use more audio apps while it's in
this state.
It's worth giving aoss a try. There's nothing to lose, and if it works, it
works.
I think you also said that gmfsk was working ok on FC6. Was that on the same
machine, with the same soundcard? If so, it is a bit strange that it's not
working on F7.
There are problems with UDEV, and I've had problems with the ordering of video
devices. Thankfully resolved for my Debian installs from help on the Debian
list, and hopefully the same fix will work on my FC installs that are using
UDEV.
All the best.
Nigel.
2:49 p.m.
Nigel Henry wrote:
On Thursday 02 August 2007 16:21, Karl Larsen wrote:
> Andy Green wrote:
>> Somebody in the thread at some point said:
>>> I read but did not understand any details of udev but I am certain
>>> it is why my old application called gmfsk finds that /dev/dsp is busy.
>>> It is not busy but the current setup of udev makes it appear busy. Also
>>> it is certain that udev can have upset with the new kernels and be
>>> causing the problems some or most of us are having.
>> What makes you think /dev/dsp isn't busy, and if it is busy, that udev
>> is to blame? Try this
>>
>> lsof -n | grep /dev/dsp
>>
>> it should list any processes that have /dev/dsp open.
>>
>> -Andy
> I did that and got no result. I think that means it is not busy?
>
>
> --
>
> Karl F. Larsen, AKA K5DI
> Linux User
> #450462 http://counter.li.org.
Hi Karl. Did you have the gmfsk ham radio app running when you tried the above
command? I seem to remember a while back that you said that rx was ok, but
you got the /dev/dsp problem when tx'ing.
Yes that is correct. It does work through the same /dev/dsp on receive
of course.
It may be worth trying starting gmfsk with aoss. You need to install the
package alsa-oss, then launch the app as.
aoss gmfsk
That is if gmsfk is the command for launching it.
I've just looked at this on one of my 2 machines that does not have a
soundcard capable of multiple audio streams. I listen to Internet radio, and
start opera with, aoss opera. This way I can use other audio apps at the same
time. I ran /usr/sbin/lsof -n | grep /dev/dsp while listening to Internet
radio, and just got a return to the command prompt. Btw www.bbc.co.uk/radio4
uses the BBC radio player, that is using RealPlayer (an OSS app).
So next I close Opera, and open Firefox, which isn't started using "aoss".
Go
to www.bbc.co.uk/radio4, click on listen live, and re-run,
/usr/sbin/lsof -n | grep /dev/dsp
This time I get the following output.
$ /usr/sbin/lsof -n | grep /dev/dsp
realplay. 29809 djmons 5w CHR 14,3 360131 /dev/dsp
Now /dev/dsp is busy, and I know I can't use more audio apps while it's in
this state.
It's worth giving aoss a try. There's nothing to lose, and if it works, it
works.
I think you also said that gmfsk was working ok on FC6. Was that on the same
machine, with the same soundcard? If so, it is a bit strange that it's not
working on F7.
There are problems with UDEV, and I've had problems with the ordering of video
devices. Thankfully resolved for my Debian installs from help on the Debian
list, and hopefully the same fix will work on my FC installs that are using
UDEV.
All the best.
Nigel.
OK I yummed the 2 files and used $ aoss gmfsk and as you expected it
worked! I will do some learning as to why in the future but thanks for
the idea. It now runs on F7
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
3:38 p.m.
On Thursday 02 August 2007 21:49, Karl Larsen wrote:
Nigel Henry wrote:
> On Thursday 02 August 2007 16:21, Karl Larsen wrote:
>> Andy Green wrote:
>>> Somebody in the thread at some point said:
>>>> I read but did not understand any details of udev but I am certain
>>>> it is why my old application called gmfsk finds that /dev/dsp is busy.
>>>> It is not busy but the current setup of udev makes it appear busy.
>>>> Also it is certain that udev can have upset with the new kernels and
>>>> be causing the problems some or most of us are having.
>>>
>>> What makes you think /dev/dsp isn't busy, and if it is busy, that udev
>>> is to blame? Try this
>>>
>>> lsof -n | grep /dev/dsp
>>>
>>> it should list any processes that have /dev/dsp open.
>>>
>>> -Andy
>>
>> I did that and got no result. I think that means it is not busy?
>>
>>
>> --
>>
>> Karl F. Larsen, AKA K5DI
>> Linux User
>> #450462 http://counter.li.org.
>
> Hi Karl. Did you have the gmfsk ham radio app running when you tried the
> above command? I seem to remember a while back that you said that rx was
> ok, but you got the /dev/dsp problem when tx'ing.
Yes that is correct. It does work through the same /dev/dsp on receive
of course.
> It may be worth trying starting gmfsk with aoss. You need to install the
> package alsa-oss, then launch the app as.
> aoss gmfsk
>
> That is if gmsfk is the command for launching it.
>
> I've just looked at this on one of my 2 machines that does not have a
> soundcard capable of multiple audio streams. I listen to Internet radio,
> and start opera with, aoss opera. This way I can use other audio apps at
> the same time. I ran /usr/sbin/lsof -n | grep /dev/dsp while listening to
> Internet radio, and just got a return to the command prompt. Btw
> www.bbc.co.uk/radio4 uses the BBC radio player, that is using RealPlayer
> (an OSS app).
>
> So next I close Opera, and open Firefox, which isn't started using
> "aoss". Go to www.bbc.co.uk/radio4, click on listen live, and re-run,
> /usr/sbin/lsof -n | grep /dev/dsp
>
> This time I get the following output.
>
> $ /usr/sbin/lsof -n | grep /dev/dsp
> realplay. 29809 djmons 5w CHR 14,3 360131
> /dev/dsp
>
> Now /dev/dsp is busy, and I know I can't use more audio apps while it's
> in this state.
>
> It's worth giving aoss a try. There's nothing to lose, and if it works,
> it works.
>
> I think you also said that gmfsk was working ok on FC6. Was that on the
> same machine, with the same soundcard? If so, it is a bit strange that
> it's not working on F7.
>
> There are problems with UDEV, and I've had problems with the ordering of
> video devices. Thankfully resolved for my Debian installs from help on
> the Debian list, and hopefully the same fix will work on my FC installs
> that are using UDEV.
>
> All the best.
>
> Nigel.
OK I yummed the 2 files and used $ aoss gmfsk and as you expected it
worked! I will do some learning as to why in the future but thanks for
the idea. It now runs on F7
--
Karl F. Larsen, AKA K5DI
Linux User
#450462 http://counter.li.org.
I'm glad that has resolved the problem for you.
Nigel.
6122
days inactive
6122
days old
19 comments
5 participants
participants (5)
-
Andy Green -
Chris Jones -
Jason L Tibbitts III -
Karl Larsen -
Nigel Henry