Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 12
To use a bell in an xterm window I have: 1) set bell-style audible in .bashrc 2) for an xterminal have set xset b 100 800 10 3) set alsamixer's ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux User
    Join Date
    Mar 2008
    Posts
    287

    Get sound from PC Speaker


    To use a bell in an xterm window I have:
    1) set bell-style audible in .bashrc
    2) for an xterminal have set xset b 100 800 10
    3) set alsamixer's card 2 "PC Speak" to 80% and unmuted
    4) loaded pcspkr with modprobe
    5) have kernel configured with:
    CONFIG_PCSPKR_PLATFORM=y and
    CONFIG_INPUT_PCSPKR=m
    6) uncommented /sbin/modprobe pcspkr in rc.modules
    7) commented blacklist pcspkr in /etc/modprobe.d/blacklist.conf
    set bell-style audible in /etc/inputrc
    but cannot cause the PC speaker to make a sound with echo -e "^G" command.
    This will work but only in console.
    Any clues for my Slackware (13.0) 2.6.29.6-smp to get a sound from PC speaker using bash in an xterm?
    Last edited by clickit; 04-26-2011 at 06:05 AM. Reason: added 6, 7 & 8

  2. #2
    Just Joined!
    Join Date
    May 2009
    Location
    Oregon
    Posts
    51
    Hmm.. in Slackware 12 & 13 on my machines just using echo -e "\a" causes the audio bell to go off. I am not familiar with control G; though pressing it in an x-term with or without quotes causes a beep on my system. The same is true on
    urxvt terminals -- I'm running windowmaker as my window-manager.

    If it works in console, then it isn't a kernel module issue. Try using the escape sequence for audio "\a" and see if it works.

  3. #3
    Linux User
    Join Date
    Mar 2008
    Posts
    287
    I too had no trouble with release 12.0. As you can see from what I had to do. The bell I learned was intentionally defeated in 13.0. If I use a console as root or a user I can get the bell. If in an xwindow then no it won't work with either echo ctrl-G or echo \a which I use in numerous scripts.

  4. #4
    Just Joined!
    Join Date
    May 2009
    Location
    Oregon
    Posts
    51

    Question Probing the audio bell blockout problem.

    Quote Originally Posted by clickit View Post
    I too had no trouble with release 12.0. As you can see from what I had to do. The bell I learned was intentionally defeated in 13.0. If I use a console as root or a user I can get the bell. If in an xwindow then no it won't work with either echo ctrl-G or echo \a which I use in numerous scripts.
    I only upgraded to 13.1, and I don't believe I reinstalled X as a whole. I seem to recall having a similar problem show up in a configuration file -- where beep was *replaced* with blink; not so good for the blind (at times). But I am not absolutely certain it was on this machine.... Do your Xterm's blink or flash when the bell ought to sound?

    I assume you have superuser priveleges, so correct me if I am wrong.

    The connection between X windows and the audio system is where the problem is going to be.
    Either the terminal program itself has to send the signal or X windows must do it.

    Even with my audio driver modules disabled, the beep is generated. No evidence of any permanent connections to *any* /dev/ device exists. $( lsof | grep /dev/ ) so there is either a custom socket/node to the pc speaker somewhere, or the X/bash programs on my system are somehow locating the virtual console (owner) from which X11 was launched and using it to produce the beep. (Virtual consoles are hardcoded to audio, I think!...)

    running a $( strace echo -e "\a" ), I find a disgustingly large number of system calls.... I am about ready to write a C program to get around this garbage. Yep, I did:
    Code:
    #include <unistd.h>
    int main(void) {
            write( STDOUT_FILENO, "\a", 1 );
    }
    OK. It beeps, still, and this program knows nothing about X *at all* nor any internal shell settings or processes. Guaranteed. All it knows is the IO stream.

    And this is what a system trace of the program looks like.

    strace ./a.out
    execve("./a.out", ["./a.out"], [/* 45 vars */]) = 0
    brk(0) = 0x804a000
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7739000
    access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
    open("/etc/ld.so.cache", O_RDONLY) = 3
    fstat64(3, {st_mode=S_IFREG|0644, st_size=97729, ...}) = 0
    mmap2(NULL, 97729, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7721000
    close(3) = 0
    open("/lib/libc.so.6", O_RDONLY) = 3
    read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\3 40l\1"..., 512) = 512
    fstat64(3, {st_mode=S_IFREG|0755, st_size=1649149, ...}) = 0
    mmap2(NULL, 1452296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75be000
    mprotect(0xb771a000, 4096, PROT_NONE) = 0
    mmap2(0xb771b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb771b000
    mmap2(0xb771e000, 10504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb771e000
    close(3) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75bd000
    set_thread_area({entry_number:-1 -> 6, base_addr:0xb75bd6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
    mprotect(0xb771b000, 8192, PROT_READ) = 0
    mprotect(0xb7758000, 4096, PROT_READ) = 0
    munmap(0xb7721000, 97729) = 0
    write(1, "\7", 1) = 1
    exit_group(1) = ?
    Process 5032 detached
    The very last thing is code seven being written to *stdout* as expected. Since X does not process IO, but the shell *does* when it prints strings -- your problem *must* be with the shell IO and not X windows as a whole. (It is the specific program XTERM or it is your shell). The settings in X *ONLY* affect what sounds X windows generates, not programs run under X. Your desk manager is thus a separate configuration as well -- your problem is quite low level/basic.

    If I do: $( echo -e '\a' | cat - > /dev/null )
    There is no beep on my system, proving X11 isn't processing my stdout streams looking for a bell signal.
    If I do: $( echo -e '\a' > /dev/stderr ), I DO get a beep. (Try that one, stderr is often processed differently than stdout.)

    Now, to nail this down a bit: Running $( ps -axjf ) will print a program tree showing parent and child programs and ultimately which tty (virtual console) they belong to. Look for X windows, startx, init, etc. whatever you start it by.... and whichever tty it lists for you is the one needing to be checked for having trouble accessing the "Beep". I suspect that you start x windows from an /etc/init.rd script?

    If so, try exiting X windows (ctrl alt backspace) and see if THAT terminal is able to beep. If it isn't you know where the problem is. If you can't exit X that way, you can kill it from another virtual console (since you can get to one) and restart a simple session using startx from a console that does beep.

    There is only one thing that could stop a shell from beeping who's parent does BEEP -- and that is if when being forked (created) it's line discipline is reprogrammed or the IO totally redirected.
    In any event, I (hopefully) have given you enough information to isolate the location of the problem, which is most likely in your *shell* startup scripts, and not X itself as a whole. (running a terminal program like URXVT will have different settings than XTERM and would probably beep if Xterm is the problem. URXVT is also a LOT faster than Xterm, and eats far less memory.) It is possible that the X-term program (alone) has a setting to disable the beeping (since it prints the characters to the X windows screen, it must process the "print" statements from all programs running under it.) So it has to be an Xterm specific setting, or your shell's specific setting causing your problem. It isn't going to be an xorg.conf type problem. (/etc/X11/xorg.conf)

    if it's an emergency... something you would like to work around by using virtual consoles to activate the beep (it's hairy, but can be done) there is a trick that can be used to redirect a COPY of an interactive shell session to be printed on an invisible console, which is able to beep. eg: a virtual terminal.

    Let me know what you discover -- I'll see if I can locate the Xterm setting for blink vs. beep (if that's what's happening).
    Last edited by andrewr; 05-19-2011 at 07:27 AM.

  5. #5
    Just Joined!
    Join Date
    May 2009
    Location
    Oregon
    Posts
    51
    hmmm... here's something interesting:
    From an xterm, launch another one:
    $xterm -mb +vb

    Now, move to the new xterm and hold a key down; at some point near the right side of the terminal -- a beep ought to sound. "-mb" turns ON the margin bell.
    "+vb" turns OFF the visual blink(bell replacement), and therefore turns the bell on if it is globally turned off somewhere else.

    I do have a full install of Slackware 13 (last version) on another machine I just realized, and I don't recall there being a no-beep situation. If none of what I am pointing out detects the problem -- I'll go check that machine. It doesn't launch the X window system from a startup script though (rc.d).

    cheers.

  6. #6
    Linux User
    Join Date
    Mar 2008
    Posts
    287

    Get sound from PC Speaker

    Wow! Andrewr, U just went over the top in help!! Its late here at this moment and must get rest for tomorrow's jumping lesson so will test out UR suggestions and get back 2 U ASAP.

  7. #7
    Linux User
    Join Date
    Mar 2008
    Posts
    287

    Get sound from PC Speaker

    OK here are the results of suggested probes:
    1) echo -e '\a' | cat - > /dev/null NO SOUND
    echo -e '\a' > /dev/stderr NO SOUND
    2) ps -axjf | egrep -i "xwindows|startx|xinit|init"
    which yields:
    Warning: bad ps syntax, perhaps a bogus '-'? See procps - Frequently Asked Questions (FAQ)
    0 1 1 1 ? -1 Ss 0 0:00 init [3]
    3200 3243 3243 3200 tty2 3243 S+ 502 0:00 \_ /bin/sh /usr/X11R6/bin/startx
    3243 3262 3243 3200 tty2 3243 S+ 502 0:00 \_ xinit /home/auser/.xinitrc -- /usr/bin/X :0 -auth /home/auser/.serverauth.3243
    3262 3268 3268 3200 tty2 3243 S 502 0:00 \_ /bin/sh /home/auser/.xinitrc
    3797 3804 3803 3797 pts/2 3803 S+ 502 0:00 \_ egrep -i xwindows|startx|xinit|init

    3) .xinitrc is where I copy the /etc/X11/xinit code to in order to startup the various window managers there via startx.When I run past right margin I get neither a bell nor a screen flash.

    4) $xterm -mb +vb
    bash: -mb: command not found

    $xterm -mb (by itself creates a new xterm and within it the bell does work)

    5) /etc/X11/xorg.conf is an empty file under 13.0 default configuration.

  8. #8
    Just Joined!
    Join Date
    May 2009
    Location
    Oregon
    Posts
    51
    The '-' on ps -axjf is my mistake -- some habits die hard.
    I am not able to replicate the '-mb' command not found, though.
    I'll have a friend test it on his Slackware 13 install and see if it happens there and let you know, soon.

  9. #9
    Linux User
    Join Date
    Mar 2008
    Posts
    287
    I was able to create an xterm window by running xterm -vb -mb and this time (who knows why??) it worked - got a bell sound as it neared the margin. Do you know of a way for me to apply this to an existing "Terminal" window (it is xterm too). I've apparently lost the means/method to do so. I've clicked preferences on the tool bar and looked in the list of apps window but don't recall how or if I applied it. I tried using the advanced tab and including -vb but I changed it back when it didn't respond as expected. Now when i man some pages I get a "WARNING: terminal is not fully functional".
    Was able to use echo -e "\a" >/dev/console as root and got the beep but still need it from Terminal as regular user.

  10. #10
    Just Joined!
    Join Date
    May 2009
    Location
    Oregon
    Posts
    51

    Wink

    Hmmm....

    OK. I wasn't able to reproduce the errors, so I assume it is specific to your machine.

    There are a couple of choices; You wrote to /dev/console -- which writes to the active console device (parent) of X windows. One option is to change the write permissions to /dev/console so that a group or all users can write to it -- but perhaps not read it (to avoid keyboard sniffing security loophole.) The output on that console can't be trusted since anyone could write it ... but that's up to you.

    I think what is going on is that the resources for your X11 xterm are not being set when it is launched to the values that you would like. X11 has a resource database for every program under X. Since this problem seems (from the debug info you gave) specific to the xterm program itself, you could load a different terminal program like urxvt which should bypass the problem. Alternatively, you can try applying an X resource as a default to the terminal:

    My system is started differently than yours, so I am going to show mine as an example -- and you may need to adjust things a little bit.

    If you have strace on your system (best option), you can actually watch the launching of an xterm with:
    strace xterm 2>&1 | grep access | less
    It will show you all the configuration files that xterm read when starting up. Mine looks like:

    access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/.Xauthority", R_OK) = 0
    access("/usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE", R_OK) = 0
    access("/home/andrewr/en_US.UTF8/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/en/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/en_US.UTF8/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/en/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/home/andrewr/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/etc/X11/en_US.UTF8/app-defaults/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/etc/X11/en/app-defaults/XTerm", R_OK) = -1 ENOENT (No such file or directory)
    access("/etc/X11/app-defaults/XTerm", R_OK) = 0
    access("/usr/share/X11/locale/en_US.UTF-8/Compose", R_OK) = 0

    On my system, the startup file for bash enables utf-8 encoding (as well as urxvt terminal program downloaded separately from Slackware.) So the first place xterm checks is the shared locale (and that is unimportant). All the rest of the default files don't exist, until the last two, and only one is important:

    '/etc/X11/app-defaults/XTerm'

    Which has an enable visual bell in it, but only as a menu item -- (click on an Xterm and then press and hold ctrl button and middle mouse at the same time to see the menu, visual bell ought to be off. ) -- and that doesn't affect my system; so my system has no enable or disable of the bell in any of the configuration files that my xterm program reads.

    You might be able to enable the bell from the xterm menu as I just mentioned.

    There is only one other place resources could have been set on X11, and that is the online resource database. Doing an: xrdb -query would list any special defaults you have.
    On my system, xrdb -query, returns nothing at all.

    Another thought you might want to check is:
    xset q # See what the bell settings are for X windows globally.
    xset b 100 2000 20 # Set the bell to 100% volume, 2000Hz, 20 milleseconds....
    If that turns out to be the problem, and you have trouble getting it into a startup script let me know.


    To see how your xterms are started (whatever started them, eg: window manager, etc), just do a window listing with the command: xlsclients
    That should help you debug what you window manager is doing to start the xterm program.

    And finally, the only other thing I can think of is to add defaults for x-windows programs in an
    ~/.Xresources file, or an ~/XTerm file.
    For example.

    ! ~/XTerm defaults for X windows (andrews)
    XTerm*bellSuppressTime: 20
    XTerm*background: yellow
    XTerm*marginBell: True
    XTerm*nMarginBell: 2
    XTerm*visualBell: False

    you can also force a load of the file into the X windows database immediately by xrdb -load XTerm , but as far as I know, resources only apply to newly started xterms and not old ones -- so it shouldn't help you any more than the ~/XTerm file.

    It is possible that the xterm in 13.xx is actually named lowercase xterm instead of XTerm; but that would show up in the system trace I recommended above, and if so -- just chance all instances of the name XTerm to xterm in the instructions I gave.

    Let us all know how you come out so others can benefit too. Good luck.

Page 1 of 2 1 2 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •