MPEG3Plugin code appears broken when generated?

 
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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: STOP: No Op

 


> On 2020-12-15, at 7:42 PM, Eliot Miranda <[hidden email]> 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.