From owner-freebsd-questions@FreeBSD.ORG Wed Apr 3 13:12:19 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1DE25FC for ; Wed, 3 Apr 2013 13:12:19 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 7015BF1C for ; Wed, 3 Apr 2013 13:12:19 +0000 (UTC) Received: from r56.edvax.de (port-92-195-80-247.dynamic.qsc.de [92.195.80.247]) by mx01.qsc.de (Postfix) with ESMTP id E775F3CC3D; Wed, 3 Apr 2013 15:12:10 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id r33DCHGI001918; Wed, 3 Apr 2013 15:12:17 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Wed, 3 Apr 2013 15:12:17 +0200 From: Polytropon To: "Ronald F. Guilmette" Subject: Re: Recipie for CPU souffle' Message-Id: <20130403151217.2144109d.freebsd@edvax.de> In-Reply-To: <25419.1364955059@server1.tristatelogic.com> References: <20130402231522.71cb7352.freebsd@edvax.de> <25419.1364955059@server1.tristatelogic.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 13:12:19 -0000 On Tue, 02 Apr 2013 19:10:59 -0700, Ronald F. Guilmette wrote: > See how the entire ioctl() interface for these device types is completely > documented IN THE MAN PAGE? That's the way it should be... None of this > rooting around in the sources for something that should have been documented > properly, external to the kernel sources. I agree that especially to developers, that sounds logical and very helpful. Seems that manpages do not aim for that goal anymore... > It doesn't have to cover "everything". But it _should_ completely describe > the programatic interface. At least is leaves questions, like stating "use the syscalls in order to...", and the reader is left with the most obvious question: _which_ syscalls? > But like I said, somewher along the line, a lot of man page writers > apparently got lazy... VERY lazy. But keep in mind they're still alive! Judging from the manpages of... *cough* can I say this? YOu know, more prominent open source operating systems for desktops... they're usually much worse _if_ there is a manpage. In most cases, there's none. > >> Second order question: Why can't I just pipe a .wav file to the > >> /dev/speaker device file and have it play? Wouldn't that make quite > >> a lot of sense? > > > >No, that does not work. > > Apparently not. > > Why it doesn't work (or couldn't work) is less clear. The speaker interface to the _PC speaker_ is not a DSP. It's programming is much simpler. The "note language" that it uses on FreeBSD is much more than other interfaces offer. Better ones have stuff like pitch, duration, turn off. Worse ones only can emit ^G (BEL character) and have some terminal driver make a "beep" and nothing more. > >However, try this example (cw.sh): > > > >#!/bin/sh > > > >read -p "CW ===> " TEXT > >echo ${TEXT} | morse | awk '{ > > if(length($0) == 0) > > printf("P4\n"); > > else { > > gsub(" dit", "P32L32E", $0); > > gsub(" di", "P32L32E", $0); > > gsub(" dah", "P32L8E", $0); > > printf("%sP16\n", $0); > > } > >}' | dd bs=256 of=/dev/speaker > /dev/null 2>&1 > > Ummm.... > > % /tmp/beeps.sh > CW ===> xxxxx > /tmp/beeps.sh: morse: not found Seems your OS is installed incompletely? % which morse /usr/games/morse This is on my home 8.2 system. The "morse" program is part of the "games" distribution. Maybe you've decided to leave it out when installing your system? Just in case, you can easily install it from the source tree, cd /usr/src/games/morse/ and make install. > >But probably not required, because the simplest test you could > >construct is something like > > > > % echo "c" > /dev/speaker > > Humm... now _that_ is both interesting and enlightening. I actually remember having used something comparable on BASIC, when my brain wasn't fully developed yet. :-) echo "cdefgab>c" > /dev/speaker It's still a nice interface to "generate attention sounds" in case you want to make an audible alarm or signal for some specific action, like a program which has aborted, an unverified backup or the successful completition of a task. > >Can you hear a sound? > > Yes. This means two things: Your speaker is present and works, and the /dev/speaker mechanism also works. > >> I wonder if whoever write and distributed this realized that he/she could > >> be sued for copyright infringement for about 5 of the simple tunes that are > >> embedded in that thing. Sad but true. > >> :-( > > > >Is it really that bad already? > > Haven't you noticed? I _try_ not to notice it, because in some cases, it's totally insane what's happenning on that front... > In the future, there will be no more engineers... only lawyers. Two lawyers, three opinions. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...