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@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

primitiveSoundPlaySamples primSoundPlaySamples invokes primitiveSoundPlaySamples which calls framesPlayed = snd_PlaySamplesFromAtLength(frameCount, (int)buf, startIndex - 1); which is the platform specific api for playing sound (frameCount) at buf starting at (startIndex -1) on unix it's really snd->snd_PlaySamplesFromAtLength so it dispatchs to the sound plugin for the unix's VM choice.

On 17-Nov-08, at 4:12 PM, Brad Fuller wrote:

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)

-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================