Objective: I'm trying to build the VM out of the box, nothing fancy. I
want to use ALSA. Problem: I'm getting segfaults when playing any audio object (from the Objects>Multimedia panel) I svn'd fresh source from the trunk, and followed the directions in README.SVN [1]. I then moved to unix subdir and made. Everything went fine, no errors and installed fine. Squeak seems to run fine.e.g. I exercised the network retrieving the Universe packages. However, when I start up an image and pull out any of the audio objects, a segfault happens immediately: Segmentation fault 17753728 [] in >playLoop 17753820 [] in Semaphore>critical: 17753544 BlockContext>ensure: 17753360 Semaphore>critical: 17720844 >playLoop 17720660 [] in >startPlayerProcessBufferSize:rate:stereo:sound: 17720752 [] in BlockContext>newProcess Aborted I get the same segfault using a command option: $ squeak -vm sound=ALSA Squeak3.10.2-7179-basic.image If I specify "none": $ squeak -vm sound=none Squeak3.10.2-7179-basic.image then no segfault, and of course, no sounds. the plugin does exist in the squeak directory: $ lsa /usr/local/lib/squeak/3.10-4 total 22540 4 drwxr-xr-x 2 root root 4096 2008-11-14 15:35 . 4 drwxr-xr-x 5 1000 1000 4096 2008-11-14 15:32 .. 28 -rwxr-xr-x 1 root root 26820 2008-11-14 15:32 AioPlugin 172 -rwxr-xr-x 1 root root 170451 2008-11-14 15:32 B3DAcceleratorPlugin 32 -rwxr-xr-x 1 root root 29332 2008-11-14 15:32 ClipboardExtendedPlugin 76 -rwxr-xr-x 1 root root 71250 2008-11-14 15:32 DBusPlugin 24 -rwxr-xr-x 1 root root 20934 2008-11-14 15:32 FileCopyPlugin 184 -rwxr-xr-x 1 root root 182395 2008-11-14 15:32 GStreamerPlugin 32 -rwxr-xr-x 1 root root 32161 2008-11-14 15:32 ImmX11Plugin 88 -rwxr-xr-x 1 root root 85971 2008-11-14 15:32 KedamaPlugin 140 -rwxr-xr-x 1 root root 138507 2008-11-14 15:32 KedamaPlugin2 44 -rwxr-xr-x 1 root root 44065 2008-11-14 15:32 MIDIPlugin 792 -rwxr-xr-x 1 root root 803221 2008-11-14 15:32 Mpeg3Plugin 24 -rwxr-xr-x 1 root root 23088 2008-11-14 15:32 npsqueak.so 36 -rwxr-xr-x 1 root root 36765 2008-11-14 15:32 PseudoTTYPlugin 144 -rwxr-xr-x 1 root root 142582 2008-11-14 15:32 RomePlugin 2472 -rwxr-xr-x 1 root root 2525072 2008-11-14 15:32 squeak 208 -rwxr-xr-x 1 root root 205337 2008-11-14 15:32 Squeak3D 17200 -rw-r--r-- 1 root root 17584742 2008-11-14 15:35 SqueakV39.sources 116 -rwxr-xr-x 1 root root 113755 2008-11-14 15:32 UnixOSProcessPlugin 20 -rwxr-xr-x 1 root root 17974 2008-11-14 15:32 UUIDPlugin 100 -rwxr-xr-x 1 root root 96184 2008-11-14 15:32 VideoForLinuxPlugin 112 -rwxr-xr-x 1 root root 110434 2008-11-14 15:32 vm-display-fbdev 28 -rwxr-xr-x 1 root root 26121 2008-11-14 15:32 vm-display-null 272 -rwxr-xr-x 1 root root 271778 2008-11-14 15:32 vm-display-X11 56 -rwxr-xr-x 1 root root 49985 2008-11-14 15:32 vm-sound-ALSA 20 -rwxr-xr-x 1 root root 16870 2008-11-14 15:32 vm-sound-null 84 -rwxr-xr-x 1 root root 79461 2008-11-14 15:32 vm-sound-OSS 28 -rwxr-xr-x 1 root root 25109 2008-11-14 15:32 XDisplayControlPlugin I thought maybe it was because SoundPlugin was not there, but it's in: $ ls src/vm/intplugins/SoundPlugin SoundPlugin.c and: $ cat src/plugins.int # Automatically generated makefile include for internal plugins INTERNAL_PLUGINS = ADPCMCodecPlugin AsynchFilePlugin BMPReadWriterPlugin B2DPlugin BitBltPlugin CroquetPlugin DSAPrims ZipPlugin DropPlugin FFTPlugin FilePlugin FloatArrayPlugin FloatMathPlugin GeniePlugin JPEGReadWriter2Plugin JPEGReaderPlugin JoystickTabletPlugin Klatt LargeIntegers LocalePlugin Matrix2x3Plugin MiscPrimitivePlugin RePlugin SecurityPlugin SerialPlugin SocketPlugin SoundCodecPrims SoundGenerationPlugin SoundPlugin StarSqueakPlugin SurfacePlugin I assume it got built and is located internally in the vm proper. Any ideas? I have a feeling I just missed something completely easy in the setup. Or, could this be because I'm running 64bit? Since everything else is working? [1] the first instruction in README.SVN is incorrect. It should be: $ svn co http://squeakvm.org/svn/squeak/trunk squeak - .i.e. the path is a bit wrong. Perhaps I should write up a bug? (should these types of messages go to the squeak-vm list? I long-ago unsubscribed to that since it had little traffic) -- Brad Fuller |
On Nov 14, 2008, at 6:56 PM, Brad Fuller wrote: > I assume it got built and is located internally in the vm proper. > > Any ideas? I have a feeling I just missed something completely easy in > the setup. > Or, could this be because I'm running 64bit? Since everything else > is working? Brad, Just a completely random hunch, but have you checked to make sure that Squeak is outputting audio at the same frequency (44.1 kHz or 48 kHz) that your Linux audio setup is set to? I apologize that I don't have more specific information re: how to achieve this in your particular setup. I know my Squeak VM crashed on OpenBSD because my audio hardware was running at I believe 22050 Hz and Squeak expected something different (e.g. 44100). Cheers, Tim J |
On Mon, Nov 17, 2008 at 12:13 PM, Tim Johnson <[hidden email]> wrote:
> > On Nov 14, 2008, at 6:56 PM, Brad Fuller wrote: > >> I assume it got built and is located internally in the vm proper. >> >> Any ideas? I have a feeling I just missed something completely easy in >> the setup. >> Or, could this be because I'm running 64bit? Since everything else is >> working? > > Brad, > > Just a completely random hunch, but have you checked to make sure that > Squeak is outputting audio at the same frequency (44.1 kHz or 48 kHz) that > your Linux audio setup is set to? I apologize that I don't have more > specific information re: how to achieve this in your particular setup. I > know my Squeak VM crashed on OpenBSD because my audio hardware was running > at I believe 22050 Hz and Squeak expected something different (e.g. 44100). That's strange that you had a crash because of that. My ALSA setup should accommodate any change, though. I've played all kinds of audio at different sample rates. I'll check, though. I think what I have to do is check out what role vm-sound-ALSA plays. I haven't had a chance yet. I hope to get to that today. sqUnixSoundALSA.c does get built (it shows up in platforms/unix/bld/vm-sound-ALSA/sqUnixSoundALSA.o -- Brad Fuller |
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 |
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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
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 <[hidden email]> 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 <[hidden email]> > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > -- Brad Fuller |
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 <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Brad Fuller-4
Hi Brad,
"playLoop" is used with a semaphore if SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: returns without error. Otherwise "oldStylePlayLoop" is used with a delay instead of the semaphore. Without debug info I cannot say for certain what the problem is but you might want to change SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: so it skips the actual call to the primitive, which will force the use of the oldStylePlayloop, and see if this gets you any where. Put some printf() statements in the C-code for quick debug info or see if there is "strace" for your platform. If you intend to do more coding at this level then gdb will probably save you a lot time in future. HTH DMOC 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, a silly question: are you using a 64 bits linux? I'm asking because your symptoms are exactly as those of http://bugs.squeak.org/view.php?id=7103
Regards José L. 2008/11/18 Derek O'Connell <[hidden email]> Hi Brad, |
On Tue, Nov 18, 2008 at 7:29 AM, José Luis Redrejo <[hidden email]> wrote:
> Brad, a silly question: are you using a 64 bits linux? I'm asking because > your symptoms are exactly as those of > http://bugs.squeak.org/view.php?id=7103 Not a silly question, I mentioned that I'm using 64bits in my original message. Thanks for the confirmation. I've traced the problem to these two lines in this function: == 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); == I have to recompile to optimize out to see what's going on (thought I did that). But, maybe someone could understand the problem by just looking at this.Maybe it's an int size, or similar, problem. sqMemoryAccess.h defines: #if defined(SQ_IMAGE32) typedef int sqInt; typedef unsigned int usqInt; #elif defined(SQ_HOST64) typedef long sqInt; typedef unsigned long usqInt; #else # if (SIZEOF_LONG_LONG != 8) # error long long integers are not 64-bits wide? # endif typedef long long sqInt; typedef unsigned long long usqInt; #endif -- Brad Fuller |
The problem might be that arrayIndex is 32bit and it is used to
calculate *samples which is 64bit. This would be a problem if arrayIndex has bit31 set. EXAMPLE: If arrayIndex comes in with bit31 set (e.g. 0x911f13fc), which is negative, the top bit is extended when *samples is calculated. samples becomes 0xffffffff911f13fc.(actual values while debugging) Perhaps the cast (void *)arrayIndex was to fix that. Here's the function... I'm referencing lines 5 and 6 of the function: ==================== 1 static sqInt sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt arrayIndex, sqInt startIndex) 2 { 3 if (output_handle) 4 { 5 void *samples= (void *)arrayIndex + startIndex * output_channels * 2; 6 int count= snd_pcm_writei(output_handle, samples, frameCount); 7 if (count < frameCount / 2) 8 { 9 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); ============ Does that seem right to you all? Maybe sqInt never gets to be long long? sqMemoryAccess.h defines: #if defined(SQ_IMAGE32) typedef int sqInt; typedef unsigned int usqInt; #elif defined(SQ_HOST64) typedef long sqInt; typedef unsigned long usqInt; #else # if (SIZEOF_LONG_LONG != 8) # error long long integers are not 64-bits wide? # endif typedef long long sqInt; typedef unsigned long long usqInt; #endif -- Brad Fuller |
On Tue, Nov 18, 2008 at 10:22 AM, Brad Fuller <[hidden email]> wrote:
> The problem might be that arrayIndex is 32bit and it is used to > calculate *samples which is 64bit. This would be a problem if > arrayIndex has bit31 set. > > EXAMPLE: If arrayIndex comes in with bit31 set (e.g. 0x911f13fc), > which is negative, the top bit is extended when *samples is > calculated. samples becomes 0xffffffff911f13fc.(actual values while > debugging) > > Perhaps the cast (void *)arrayIndex was to fix that. > > Here's the function... I'm referencing lines 5 and 6 of the function: > > ==================== > 1 static sqInt sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt > arrayIndex, sqInt startIndex) > 2 { > 3 if (output_handle) > 4 { > 5 void *samples= (void *)arrayIndex + startIndex * output_channels * 2; > 6 int count= snd_pcm_writei(output_handle, samples, frameCount); > 7 if (count < frameCount / 2) > 8 { > 9 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); > ============ > > > Does that seem right to you all? > > Maybe sqInt never gets to be long long? sqMemoryAccess.h defines: > > #if defined(SQ_IMAGE32) > typedef int sqInt; > typedef unsigned int usqInt; > #elif defined(SQ_HOST64) > typedef long sqInt; > typedef unsigned long usqInt; > #else > # if (SIZEOF_LONG_LONG != 8) > # error long long integers are not 64-bits wide? > # endif > typedef long long sqInt; > typedef unsigned long long usqInt; > #endif oh... I should add I see warnings during compilation. This is applicable: platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c: In function 'sound_PlaySamplesFromAtLength': platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c:204: warning: cast to pointer from integer of different size Line 204 in this error is line 5 above -- Brad Fuller |
In reply to this post by Brad Fuller-4
On Thu, Nov 20, 2008 at 3:17 PM, Brad Fuller <[hidden email]> wrote:
> On Wed, Nov 19, 2008 at 4:19 AM, David T. Lewis <[hidden email]> wrote: >> You can get a VMMaker with SlangBrowser support from SqueakSource. >> VMMaker-dtl.107 would be the most recent in that branch. > > Where can I find VMMaker 107? I only see 106 on SqueakSource Also, how does one use the SlangBrowser? I don't see it anywhere. I also don't think that the vm-sound-ALSA C code was generated from Slang. I can't seem to locate it, so I assume that it was generated outside of Squeak. Can anyone (Ian?) confirm this? -- Brad Fuller |
On Thu, Nov 20, 2008 at 03:58:08PM -0800, Brad Fuller wrote:
> On Thu, Nov 20, 2008 at 3:17 PM, Brad Fuller <[hidden email]> wrote: > > Also, how does one use the SlangBrowser? I don't see it anywhere. Find the far-right button on a class browser, where is says "source". Click on that and select "translate inlined C" or "translate to C". Or you can evaluate "FilePlugin asCString". http://wiki.squeak.org/squeak/5916 > I also don't think that the vm-sound-ALSA C code was generated from > Slang. I can't seem to locate it, so I assume that it was generated > outside of Squeak. Can anyone (Ian?) confirm this? Correct, it is not generated. Ian wrote it. Dave |
Free forum by Nabble | Edit this page |