Homebrew Homebrew Development

[Rinnegatamante]

I think I may have misunderstood your issue. Is the issue with the encoded file such that a different player- for instance on a pc - exhibits the same playback sync issue? Or is it only an issue on the 3ds?

JPGV player doesn't exist for PC.

 

[elhobbs]

JPGV player doesn't exist for PC.

the question I am asking is this: is the issue with the encoding or the playback?

 

[Rinnegatamante]

the question I am asking is this: is the issue with the encoding or the playback?

Playback.

 

[elhobbs]

Playback.

you could compare the os timer against the csndGetState buffer position and make sure it is working as expected.

 

[Rinnegatamante]

you could compare the os timer against the csndGetState buffer position and make sure it is working as expected.

I use an old version of csnd so i can't use csndGetState. Anyway, if there are some problem with timer, i just get a corrupted audio as result i think cause streaming won't update properly the audiobuffers.

 

[elhobbs]

if the audio play starts and finishes at the right time then you are right. one or the other obviously does not.

 

[DiscostewSM]

Ok, splitting the shader types to their own files, with their own outmaps, did the trick. Required a little bit more code and inclusions for initializing them, but nonetheless it worked.

 

[elhobbs]

Ok, splitting the shader types to their own files, with their own outmaps, did the trick. Required a little bit more code and inclusions for initializing them, but nonetheless it worked.

this seems more like a limitation of aemstro_as rather than ctrulib. as each dvle outmap can be unique in ctrulib. I think the issue is that aemstro_as uses the same one for both rather than allowing them to be declared independently.

 

[DiscostewSM]

this seems more like a limitation of aemstro_as rather than ctrulib. as each dvle outmap can be unique in ctrulib. I think the issue is that aemstro_as uses the same one for both rather than allowing them to be declared independently.

Yeah, that's what I was thinking. For the moment while the current setup doesn't allow having each shader with their own outmaps in the same file, this will have to do. Guess we can ask Smealum if he's willing to make an alteration, like changing .out to separate .vout and .gout

 

[elhobbs]

Yeah, that's what I was thinking. For the moment while the current setup doesn't allow having each shader with their own outmaps in the same file, this will have to do. Guess we can ask Smealum if he's willing to make an alteration, like changing .out to separate .vout and .gout

that would be doable I think. internally split _outmap into _voutmap and _goutmap. have .out add to both and .vout and .gout only add to their respective lists. Then in tobinary write either _voutmap or _goutmap depending on type - vsh or gsh. you can always create a pull request with the changes rather than waiting on smealum to implement something.

 

[DiscostewSM]

that would be doable I think. internally split _outmap into _voutmap and _goutmap. have .out add to both and .vout and .gout only add to their respective lists. Then in tobinary write either _voutmap or _goutmap depending on type - vsh or gsh. you can always create a pull request with the changes rather than waiting on smealum to implement something.

Well, I already asked about it, but he didn't see the point. I don't think he understood what I meant, since he mentioned semantics for the vertex shader in the presence of a geoshader, when all we really need is a count (and mask?) of output registers going from one to the other.

 

[Rinnegatamante]

Can a

if the audio play starts and finishes at the right time then you are right. one or the other obviously does not.

Audioplay starts good and finishes before the end of the video but audio is good.
If you want to check by yourself what i'm talking about, here you can find a modified Sunshell with Vorbis audiocodec support fort JPGV videos and the same video encoded with PCM16 and VORBIS audiocodec: http://rinnegatamante.netsons.org/test_video.rar

 

[elhobbs]

Can a


Audioplay starts good and finishes before the end of the video but audio is good.
If you want to check by yourself what i'm talking about, here you can find a modified Sunshell with Vorbis audiocodec support fort JPGV videos and the same video encoded with PCM16 and VORBIS audiocodec: http://rinnegatamante.netsons.org/test_video.rar

I will take a look. is it possible vorbis is converting the rate to a standard rate? 22025 instead of 24000?

 

[elhobbs]

I will take a look. is it possible vorbis is converting the rate to a standard rate? 22025 instead of 24000?

Can you look at or save off the temp files that are being generated during the conversion? There might be some clues if you can compare them at different stages. The pcm sound has an alternating hissing sound - it is more obvious after the intro music is finished. The vorbis does have a slight tick but it is hard to tell if it is just a compression issue.

 

[Rinnegatamante]

Can you look at or save off the temp files that are being generated during the conversion? There might be some clues if you can compare them at different stages. The pcm sound has an alternating hissing sound - it is more obvious after the intro music is finished. The vorbis does have a slight tick but it is hard to tell if it is just a compression issue.

I added two debug functions, one who shows the stream buffer size and the other who shows decoded vorbis pack size for each updateStream.
Seems i'm loosing bytes, (an average of 1 KB for each updateStream, cause blocksize is 160.688 and vorbis pack size is not costant but is always a bit larger than blocksize) so probably the issue is caused by this.

As i told, this is the problem, finally solved and got fully syncro video/audio.

 

[elhobbs]

I added two debug functions, one who shows the stream buffer size and the other who shows decoded vorbis pack size for each updateStream.
Seems i'm loosing bytes, (an average of 1 KB for each updateStream, cause blocksize is 160.688 and vorbis pack size is not costant but is always a bit larger than blocksize) so probably the issue is caused by this.

As i told, this is the problem, finally solved and got fully syncro video/audio.

Nicely done. Glad you finally found the issue.

 

[smealum]

Well, I already asked about it, but he didn't see the point. I don't think he understood what I meant, since he mentioned semantics for the vertex shader in the presence of a geoshader, when all we really need is a count (and mask?) of output registers going from one to the other.

i did understand. you were suggesting we switch the .out directive to .vout and .gout mirrors. i stand by the idea that that would not make sense, if only because it would introduce unnecessary information (vsh output has no semantics if gsh is present) while lacking other information necessary for it to be complete (gsh input stride). i also feel like trying to fix this in aemstro is a waste of time if the long term goal is not to use it. aemstro's gsh support is a hack at best, if only because it forces the sharing of resources such as code and uniforms/constants between gsh and vsh (it shouldn't). instead of wanting to keep hacking it up i feel like people should try and move towards something more sustainable. that can either be one of the other two assemblers (picasso and nihstro), or it can be making aemstro into something actually robust. i wouldn't recommend the latter, but either way you're "solution" is not the way to do it.

 

[elhobbs]

i did understand. you were suggesting we switch the .out directive to .vout and .gout mirrors. i stand by the idea that that would not make sense, if only because it would introduce unnecessary information (vsh output has no semantics if gsh is present) while lacking other information necessary for it to be complete (gsh input stride). i also feel like trying to fix this in aemstro is a waste of time if the long term goal is not to use it. aemstro's gsh support is a hack at best, if only because it forces the sharing of resources such as code and uniforms/constants between gsh and vsh (it shouldn't). instead of wanting to keep hacking it up i feel like people should try and move towards something more sustainable. that can either be one of the other two assemblers (picasso and nihstro), or it can be making aemstro into something actually robust. i wouldn't recommend the latter, but either way you're "solution" is not the way to do it.

If you would be willing to explain this a little more I would appreciate it. In the context of the issue he is describing and the solution that he used to fix the issue - it would seem reasonable that the outmap for vsh and gsh should be able to be defined separately. Is that not the proper solution? What would the proper solution look like?

 

[DiscostewSM]

Hmm, until improvements are made, why not something like adding an attribute mask to the shaderProgramSetGsh function alongside the stride? That was kinda how StapleButter handled things with blargSNES prior to the gpu revamp, although he assigned the attribute mask and stride into their own function.

Result shaderProgramSetGsh(shaderProgram_s* sp, DVLE_s* dvle, u8 stride, u8 attr_mask)
{
    ...
    sp->geometryShaderInputStride = stride;
    sp->vertexShaderAttributeMask = attr_mask;
    u32 attr_cnt = 0;
    while(attr_mask)
    {
        if(attr_mask & 1) attr_cnt++;
        attr_mask >>= 1;
    }
    sp->vertexShaderAttributeCount = attr_cnt;
    ...
}
 
 
Result shaderProgramUse(shaderProgram_s* sp)
{
    ...
    if(sp->vertexShaderAttributeMask)
    {
        GPUCMD_AddWrite(GPUREG_VSH_OUTMAP_MASK, sp->vertexShaderAttributeMask);
        GPUCMD_AddWrite(GPUREG_024A, sp->vertexShaderAttributeCount-1);
        GPUCMD_AddWrite(GPUREG_0251, sp->vertexShaderAttributeCount-1);
    } else {
        GPUCMD_AddWrite(GPUREG_VSH_OUTMAP_MASK, vshDvle->outmapMask);
        GPUCMD_AddWrite(GPUREG_024A, vshDvle->outmapData[0]-1);
        GPUCMD_AddWrite(GPUREG_0251, vshDvle->outmapData[0]-1);
    }
    ...
}

If you enter 0 for the mask, it'll default to the current implementation of how the outmaps were done when using the shader. Else, it'll use the mask and the attribute count generated from it.

 

[Rinnegatamante]

Got an error during a compilation, probably cause by too big library?

3dsxtool test.elf test.3dsx
11199116 relSymAddr=015D0BF0 relSrcAddr=00B25B40 topAddr=0155B000
Relocation to invalid address!

Library i need to link is 28.649 KBs and my elf file is 27.001 KBs.
Any help?