Thanks for the reply, John.

Yeah, I know what THAT code looks like.. it's only my speculation that
the Squeak primitive is calling this function.  My first question was
does "primSoundPlaySamples"  _directly_ call PlaySamplesFromLength in
the ALSA c code? Or, put a better way, how do I tell which smalltalk
method calls which c code function? Is there a table of pointers
somewhere? (sorry, I might have known this before, but I can't
remember and I don't know where this is on the wiki. But, after I send
this msg I'm looking for it again.)

Yeah, the args look correct in Squeak. This is an unmodified image, so
I assume there shouldn't be any problem there. I guess I have to fire
up gdb and see if the args are really correct at that stage. Just was
hoping that someone would tell me that I didn't set up configure
correctly for the make -- or that I missed something in the confugure
to include ALSA in the build. ( I just have the feeling that the ALSA
code is not being executed.,, i.e. it's not a bug in ALSA, but it's
going into the weeds... well. obviously it's going into the weeds, but
not because of ALSA code)


On Mon, Nov 17, 2008 at 3:40 PM, John M McIntosh
<johnmci at smalltalkconsulting.com> wrote:
> GDB is your friend.
>
> PlaySamplesFromAtLength
> is where we take the bytes from squeak and write them to the platform's
> sound logic. In this case for
> sqUnixSoundALSA.c
> the code is below
>
> You need to confirm startIndex, output_channels, output_handle, samples are
> all sane. In debugging past issue with
> the sound API I can say we don't consider if the parms can be bogus as a
> result of attempting to drive
> the sound primitives when we haven't really setup the sound logic properly.
>
> static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt
> arrayIndex, sqInt startIndex)
> {
>  if (output_handle)
>    {
>      void *samples= (void *)arrayIndex + startIndex * output_channels * 2;
>      int   count=   snd_pcm_writei(output_handle, samples, frameCount);
>      if (count < frameCount / 2)
>        {
>          output_buffer_frames_available= 0;
>        }
>      if (count < 0)
>        {
>          if (count == -EPIPE)    /* underrun */
>            {
>              int err;
>              snd(pcm_prepare(output_handle), "sound_PlaySamples:
> snd_pcm_prepare");
>              return 0;
>            }
>          fprintf(stderr, "snd_pcm_writei returned %i\n", count);
>          return 0;
>        }
>      return count;
>    }
>  success(false);
>  return 0;
> }
>
>
>
> On 17-Nov-08, at 3:02 PM, Brad Fuller wrote:
>
>> I'm not any further, but this is what I've found:
>>
>> I seem to get the segfault it SoundPlayer>>playLoop at:
>>
>>                        self primSoundPlaySamples: count from: Buffer
>> startingAt: 1.
>>
>> But, I don\' know really where to go from here. I checked out
>> SoundPlugin and sqUnixSoundALSA.c
>> and they both have the function:
>>
>>  int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
>> startIndex)
>>
>> which I assume is what is being called from Squeak.
>>
>> When I run 'configure', the audio section that is sent to the terminal
>> looks correct:
>>
>> checking for Advanced Linux Sound Architecture... yes
>> checking for Mac OS X CoreAudio... no
>> ******** disabling vm-sound-MacOSX
>> checking for Network Audio System... no
>> ******** disabling vm-sound-NAS
>> checking for Advanced Linux Sound Architecture... yes
>> checking for SunOS/Solaris audio... no
>> ******** disabling vm-sound-Sun
>> checking for custom sound support... no
>> ******** disabling vm-sound-custom
>>
>> (don't know why ALSA is mentioned twice, though.)
>>
>> Here's the segfault again:
>>
>> Segmentation fault
>>
>> 20547312 [] in >playLoop
>> 20547404 [] in Semaphore>critical:
>> 20547220 BlockContext>ensure:
>> 20547128 Semaphore>critical:
>> 20515212 >playLoop
>> 20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
>> 20515120 [] in BlockContext>newProcess
>> Aborted
>>
>> BTW, it didn't matter when I changed the sample rate to 44100, still
>> had the segfault.
>>
>> I don't know where to turn from here, short of compiling with debug
>> flag on and starting up gdb.
>> Any ideas much appreciated. If someone knows the architecture of what
>> happens when the primitive is called and what should happen in the
>> ALSA plugin code that could be helpful.
>>
>> thanks for reading!
>>
>>
>> --
>> Brad Fuller
>>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>



-- 
Brad Fuller