Is anybody else doing anything with MP3 files? It looks like we haven't included any image-side support for them for several releases now (I've look back to 4.5) but it is/was working just fine for the work I did on Pi Scratch. That was, admittedly, quite a while ago.
In the current system I can load much of Scratch without too many issues - sounds are really messed up in various places, some morph building is broken etc - but today I'm trying to see why mp3 sounds don't.
It seems that the code for the src/plugins/Mpeg3Plugin.c is broken. The autogenerated checks for the types of the arguments is insisting that be indexable pointers, when is is in fact a variable word array. That at least explains why the prim fails, which is at least a step forward.
Current code on opensmalltalk git -
/* int mpeg3_read_audio(mpeg3_t *file, float *output_f, short *output_i, int channel, long samples, int stream) */
/* Mpeg3Plugin>>#primitiveMPEG3ReadAudio:shortArray:channel:samples:stream: */ EXPORT(sqInt) primitiveMPEG3ReadAudio(void) { sqInt aChannelNumber; sqInt aNumber; sqInt *anArray; short *arrayBase; sqInt aSampleNumber; mpeg3_t *file; sqInt fileHandle; sqInt result;
result = 0; if (!(((isPointers(stackValue(3))) && (isIndexable(stackValue(3)))) && ((isIntegerObject((aChannelNumber = stackValue(2)))) && ((isIntegerObject((aSampleNumber = stackValue(1)))) && (isIntegerObject((aNumber = stackValue(0)))))))) { primitiveFailFor(PrimErrBadArgument); return null; }
The two interesting things I have remaining energy to point out today - The Slang does explicitly and wrongly declare it as
self primitive: 'primitiveMPEG3ReadAudio' parameters: #(Oop Array SmallInteger SmallInteger SmallInteger).
.. which clearly doesn't help. It has, however, been that way since 2006.
And the old C file from Back Then has
result = 0; fileHandle = stackValue(4); success(isIndexable(stackValue(3))); anArray = ((sqInt *) (firstIndexableField(stackValue(3)))); aChannelNumber = stackIntegerValue(2); aSampleNumber = stackIntegerValue(1); aNumber = stackIntegerValue(0); if (failed()) { return null; } .. and so it makes kinda sense why it worked Back Then.
Thus I am inclined (and not just because I'm falling asleep) to think that some change in how the prologue stuff is generated might have started to note the Array declaration and become more zealous.
More when awake.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: STOP: No Op
OK, I woke up with a start and an idea. Changing to 'WordArray' and recompiling... made mp3 files play.
I wonder if there are any other places needing changing. Tomorrow...
On 2020-12-12, at 6:07 PM, tim Rowledge tim@rowledge.org wrote:
Is anybody else doing anything with MP3 files? It looks like we haven't included any image-side support for them for several releases now (I've look back to 4.5) but it is/was working just fine for the work I did on Pi Scratch. That was, admittedly, quite a while ago.
In the current system I can load much of Scratch without too many issues - sounds are really messed up in various places, some morph building is broken etc - but today I'm trying to see why mp3 sounds don't.
It seems that the code for the src/plugins/Mpeg3Plugin.c is broken. The autogenerated checks for the types of the arguments is insisting that be indexable pointers, when is is in fact a variable word array. That at least explains why the prim fails, which is at least a step forward.
Current code on opensmalltalk git -
/* int mpeg3_read_audio(mpeg3_t *file, float *output_f, short *output_i, int channel, long samples, int stream) */
/* Mpeg3Plugin>>#primitiveMPEG3ReadAudio:shortArray:channel:samples:stream: */ EXPORT(sqInt) primitiveMPEG3ReadAudio(void) { sqInt aChannelNumber; sqInt aNumber; sqInt *anArray; short *arrayBase; sqInt aSampleNumber; mpeg3_t *file; sqInt fileHandle; sqInt result;
result = 0; if (!(((isPointers(stackValue(3))) && (isIndexable(stackValue(3)))) && ((isIntegerObject((aChannelNumber = stackValue(2)))) && ((isIntegerObject((aSampleNumber = stackValue(1)))) && (isIntegerObject((aNumber = stackValue(0)))))))) { primitiveFailFor(PrimErrBadArgument); return null; }
The two interesting things I have remaining energy to point out today - The Slang does explicitly and wrongly declare it as
self primitive: 'primitiveMPEG3ReadAudio' parameters: #(Oop Array SmallInteger SmallInteger SmallInteger).
.. which clearly doesn't help. It has, however, been that way since 2006.
And the old C file from Back Then has
result = 0; fileHandle = stackValue(4); success(isIndexable(stackValue(3))); anArray = ((sqInt *) (firstIndexableField(stackValue(3)))); aChannelNumber = stackIntegerValue(2); aSampleNumber = stackIntegerValue(1); aNumber = stackIntegerValue(0); if (failed()) { return null; } .. and so it makes kinda sense why it worked Back Then.
Thus I am inclined (and not just because I'm falling asleep) to think that some change in how the prologue stuff is generated might have started to note the Array declaration and become more zealous.
More when awake.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: STOP: No Op
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: POI: Power Off Intermittently
Hmph. So I see that the mpeg3plugin actually got slang-updated a couple of weeks back and actually fixed this issue, but the plugin C code hasn't been regenerated in 3+ months.
Sure, *I* can generate the stuff, I can probably remember how to use it anyway, but it could cause confusion for anyone less steeped in the lore. And please don't anyone suggest I try to make this git stuff do anything.
On 2020-12-12, at 10:02 PM, tim Rowledge tim@rowledge.org wrote:
OK, I woke up with a start and an idea. Changing to 'WordArray' and recompiling... made mp3 files play.
I wonder if there are any other places needing changing. Tomorrow...
On 2020-12-12, at 6:07 PM, tim Rowledge tim@rowledge.org wrote:
Is anybody else doing anything with MP3 files? It looks like we haven't included any image-side support for them for several releases now (I've look back to 4.5) but it is/was working just fine for the work I did on Pi Scratch. That was, admittedly, quite a while ago.
In the current system I can load much of Scratch without too many issues - sounds are really messed up in various places, some morph building is broken etc - but today I'm trying to see why mp3 sounds don't.
It seems that the code for the src/plugins/Mpeg3Plugin.c is broken. The autogenerated checks for the types of the arguments is insisting that be indexable pointers, when is is in fact a variable word array. That at least explains why the prim fails, which is at least a step forward.
Current code on opensmalltalk git -
/* int mpeg3_read_audio(mpeg3_t *file, float *output_f, short *output_i, int channel, long samples, int stream) */
/* Mpeg3Plugin>>#primitiveMPEG3ReadAudio:shortArray:channel:samples:stream: */ EXPORT(sqInt) primitiveMPEG3ReadAudio(void) { sqInt aChannelNumber; sqInt aNumber; sqInt *anArray; short *arrayBase; sqInt aSampleNumber; mpeg3_t *file; sqInt fileHandle; sqInt result;
result = 0; if (!(((isPointers(stackValue(3))) && (isIndexable(stackValue(3)))) && ((isIntegerObject((aChannelNumber = stackValue(2)))) && ((isIntegerObject((aSampleNumber = stackValue(1)))) && (isIntegerObject((aNumber = stackValue(0)))))))) { primitiveFailFor(PrimErrBadArgument); return null; }
The two interesting things I have remaining energy to point out today - The Slang does explicitly and wrongly declare it as
self primitive: 'primitiveMPEG3ReadAudio' parameters: #(Oop Array SmallInteger SmallInteger SmallInteger).
.. which clearly doesn't help. It has, however, been that way since 2006.
And the old C file from Back Then has
result = 0; fileHandle = stackValue(4); success(isIndexable(stackValue(3))); anArray = ((sqInt *) (firstIndexableField(stackValue(3)))); aChannelNumber = stackIntegerValue(2); aSampleNumber = stackIntegerValue(1); aNumber = stackIntegerValue(0); if (failed()) { return null; } .. and so it makes kinda sense why it worked Back Then.
Thus I am inclined (and not just because I'm falling asleep) to think that some change in how the prologue stuff is generated might have started to note the Array declaration and become more zealous.
More when awake.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: STOP: No Op
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: POI: Power Off Intermittently
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim State-of-the-art: What we could do with enough money.
On 2020-12-13, at 2:57 PM, tim Rowledge tim@rowledge.org wrote:
Hmph. So I see that the mpeg3plugin actually got slang-updated a couple of weeks back and actually fixed this issue, but the plugin C code hasn't been regenerated in 3+ months.
Wait, what? It's not there now. Sigh. Evidently I'm seeing into different futures or something. This is not good; last time that happened everyone stopped being dinosaurian.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't compare floating point numbers solely for equality.
Tim writes:
Sure, *I* can generate the stuff, I can probably remember how to use it anyway, but it could cause confusion for anyone less steeped in the lore. And please don't anyone suggest I try to make this git stuff do anything.
Ooh, that's an interesting idea... I can tell this is your big moment to learn all about GitHub Actions... ;)
-C
-- Craig Latta :: research computer scientist Black Page Digital :: Berkeley, California 663137D7940BF5C0AFC 1349FB2ADA32C4D5314CE
Hi Tim,
On Sat, Dec 12, 2020 at 6:07 PM tim Rowledge tim@rowledge.org wrote:
Is anybody else doing anything with MP3 files? It looks like we haven't included any image-side support for them for several releases now (I've look back to 4.5) but it is/was working just fine for the work I did on Pi Scratch. That was, admittedly, quite a while ago.
In the current system I can load much of Scratch without too many issues - sounds are really messed up in various places, some morph building is broken etc - but today I'm trying to see why mp3 sounds don't.
It seems that the code for the src/plugins/Mpeg3Plugin.c is broken. The autogenerated checks for the types of the arguments is insisting that be indexable pointers, when is is in fact a variable word array. That at least explains why the prim fails, which is at least a step forward.
Current code on opensmalltalk git -
/* int mpeg3_read_audio(mpeg3_t *file, float *output_f, short *output_i, int channel, long samples, int stream) */
/*
Mpeg3Plugin>>#primitiveMPEG3ReadAudio:shortArray:channel:samples:stream: */ EXPORT(sqInt) primitiveMPEG3ReadAudio(void) { sqInt aChannelNumber; sqInt aNumber; sqInt *anArray; short *arrayBase; sqInt aSampleNumber; mpeg3_t *file; sqInt fileHandle; sqInt result;
result = 0; if (!(((isPointers(stackValue(3))) && (isIndexable(stackValue(3)))) && ((isIntegerObject((aChannelNumber = stackValue(2)))) && ((isIntegerObject((aSampleNumber = stackValue(1)))) && (isIntegerObject((aNumber = stackValue(0)))))))) { primitiveFailFor(PrimErrBadArgument); return null; }
The two interesting things I have remaining energy to point out today - The Slang does explicitly and wrongly declare it as
self primitive: 'primitiveMPEG3ReadAudio' parameters: #(Oop Array SmallInteger SmallInteger SmallInteger).
.. which clearly doesn't help. It has, however, been that way since 2006.
And the old C file from Back Then has
result = 0; fileHandle = stackValue(4); success(isIndexable(stackValue(3))); anArray = ((sqInt *) (firstIndexableField(stackValue(3)))); aChannelNumber = stackIntegerValue(2); aSampleNumber = stackIntegerValue(1); aNumber = stackIntegerValue(0); if (failed()) { return null; }
.. and so it makes kinda sense why it worked Back Then.
Ah, thank you. That explains things. I had to change the checking to be more aggressive so that Spur's lazy forwarding would work. I had to arrange that such code would fail for forwarders. So I had to change the generated Slang so that it tested for a particular kind of array, rather than not testing at all and hence potentially passing a pointer to a forwarder.
Thus I am inclined (and not just because I'm falling asleep) to think that some change in how the prologue stuff is generated might have started to note the Array declaration and become more zealous.
Exactly. Spur requires the extra zealousness.
More when awake.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: STOP: No Op
On 2020-12-15, at 7:42 PM, Eliot Miranda eliot.miranda@gmail.com wrote: [snip]
Ah, thank you. That explains things. I had to change the checking to be more aggressive so that Spur's lazy forwarding would work. I had to arrange that such code would fail for forwarders. So I had to change the generated Slang so that it tested for a particular kind of array, rather than not testing at all and hence potentially passing a pointer to a forwarder.
OK, I see. Well, I put WordArray in (and the re-read prim too) and it now works ok on a Pi and hopefully somebody else will test the latest code on other platforms soon. I think the github thing did an autogenerate ok after looking at the C file. Always interesting working out what is happening when it isn't some code that changed but rather a dog that didn't bark in the night...
Now I wish I could work out why I get so much nasty crackle-graunch sound when any sound mixing is done. I'll leave that to another thread in squeak-dev though since I suspect it is not very VM specific.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sweet sorrow
On Tue, Dec 15, 2020 at 7:56 PM tim Rowledge tim@rowledge.org wrote:
On 2020-12-15, at 7:42 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
[snip]
Ah, thank you. That explains things. I had to change the checking to
be more aggressive so that Spur's lazy forwarding would work. I had to arrange that such code would fail for forwarders. So I had to change the generated Slang so that it tested for a particular kind of array, rather than not testing at all and hence potentially passing a pointer to a forwarder.
OK, I see. Well, I put WordArray in (and the re-read prim too) and it now works ok on a Pi and hopefully somebody else will test the latest code on other platforms soon. I think the github thing did an autogenerate ok after looking at the C file. Always interesting working out what is happening when it isn't some code that changed but rather a dog that didn't bark in the night...
I did it. I loaded your package, regenerated the plugin using the VMMakerTool, and committed and pushed.
Now I wish I could work out why I get so much nasty crackle-graunch sound
when any sound mixing is done. I'll leave that to another thread in squeak-dev though since I suspect it is not very VM specific.
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org