[nas] segfault on amd64

[David Liontooth]

Jon Trulson wrote:

> On Thu, 30 Dec 2004, David Liontooth wrote:
>
>     Hello David,
>
>     The config file allows you to specify the characteristics of your 
> input and output hardware devices (number of channels, sample size, 
> etc.).
>
>     When the blurb on the website says 'NAS is the audio equivalent of 
> an Xserver' it means just that.
>
>     In X, you typically fire up an Xserver, and then connect clients 
> to it.  That exactly what NAS does.  You run the nasd server on the 
> machine with the actual audio hardware, and connect clients to it for 
> playing audio.

Sounds great -- you're a great salesman, making it sound really simple 
(now let's hope for truth in advertizing) <gg>

>
>> What I want to do is to use alsaplayer -nas on box A and
>> play the sound on box B -- wouldn't this be the typical
>> usage?
>>
>
>     Yes, this is the typical usage.  I have no experience with 
> alsaplayer - I primarily use xmms, mplayer and festival with NAS.  I 
> have one box with a sound card and where the nasd server runs.  Other 
> machines on the network play their sounds on the box via NAS.
>
Cool. I run KDE on a local laptop, but most of the applications are run 
remotely from an amd64. I just need to get sound going.

>> The instructions are unusually cryptic.  I followed the only
>> ones I could find:
>>
>> $  nasd -aa &        # -aa allows any host access
>> $  export AUDIOSERVER="`hostname`:0"
>> $  auinfo
>
>
>     In X equivalent, it would be like:
>
>     X -ac &
>     export DISPLAY=:0
>     xdpyinfo &
>
I still don't get it. I don't want display :0, I want the sound to get 
to the remote box. Sorry if I'm slow, but I still don't see how this is 
done. 

>     I guess the instructions assume familiarity with X11.

Let's drop that assumption, just for pretend. To run applications 
remotely through X11, I do this:

Machine A:  /etc/ssh/ssh_config ForwardX11 yes
Machine B: /etc/ssh/sshd_config X11Forwarding yes

A: ssh B application

In the case of NAS, I would expect something like this:

B: nasd -aa &
B: export AUDIOSERVER=A:0
B: xmms

Sound comes out of A.  I'm missing something, right?  Just as an 
experiment, try using machine names A and B instead of "the client"
and "the server" (or not telling the user which machine should issue the 
command).

>
>     Most sound cards have both in input and output capability.

Very true -- so the remote system's input channel is also exported?
In that case, why is the default configuration file using one
/dev node for input (I don't have a /dev/dsp1) and another for output?

inputsection

        device          "/dev/dsp1"             # The input device, usually
        mixer           "/dev/mixer1"           # mixer device

outputsection
        device          "/dev/dsp"              # The output device, usually
        mixer           "/dev/mixer"            # mixer device

Sorry, this still makes no sense to me.

> The NAS application is responsible for choosing the appropriate device 
> from the available ones.

Great.

>     Try something simpler first:
>
>     export AUDIOSERVER=<machine where nas is running>:0
>     auplay <some random .wav file>
>
>     If you hear it, then you know NAS is probably functioning properly.

Could you repeat these instructions indicating which machine you issue 
them on?
Sorry to be terribly slow, but what would make sense to me is this 
(repeating myself):

A is my laptop where I sit, B is my server where the sound originates.

B: nasd -aa &
B: export AUDIOSERVER=A:0
B: auplay test.wav

Sound comes out of A.

Is this what should be happening?

>
>     I do accept patches for documentation as well as code :)
>
>     If you have suggestions as to what kind of documentation should be 
> provided let me know.
>
Well, first I have to understand a *little* bit of what's going on, 
right? <g>

>
>     Did you read any further?  The original postscript (I have never 
> had the 'src' for the actual document(s)) is screwed up - the pages 
> are in reverse order (look at the page numbers).  There are pdf 
> versions available (with the same problem) as well.  Start at the 
> bottom of the document and page upwards, or print it and reorganize as 
> you see fit.  (I suspect it was formatted this way for printing 
> purposes.)  Since I don't have the 'src' for these documents, I would 
> need to redo them from scratch to fix this.


>
>     I think you may be having issues with ghostview then (or the PS is 
> so old gs doesn't know what to do with it)... Try the pdf links at the 
> above page, there are 18 slides in xcon94slide.  The pdfs were made by 
> ps2pdf.
>
kpdf sees nothing. kghostview sees one page (presumably the last) -- a 
list of references. There are no pages to page up to. But plain old gs 
does see it -- as you describe, it displays the last one first, and you 
have to know to page down to see the previous.  You have to admit this 
is the epitomy of unix hackerdom. A new user of Linux would have no clue 
how to access this document (I've never had to use gs before).  Does gs 
have a command that lets you print a single page? Couldn't we do 
something like print each page to a new file and then reassemble in the 
right order, hopefully in a format that is more easily read by regular 
pdf readers? (Admittedly, kpdf often fails on new pdf documents too.)

>> The man pages are decent but they assume you already know how to use 
>> the program.
>>
>
>     So you think some kind of overview document needs to be present? 
> What technical level?

A simple howto would be handy, assuming nothing more than the ability to 
edit a config file and issue commands on the command line.  Let's bring 
NAS to the masses (joke, but why not).

Cheers,
Dave