Sorry, I don't see what is the issue with 08 which is different from 03 and 04. It contains same spikes as before. The picture you attached is a bit irrelevant, you opened file as 32-bit so it is displayed like random noise. When you open raw files make sure you point the proper format 16khz 16bit mono.
That said, I would look to speedup the decoder and make the decoding smoother. It's hard to plan that for me without the device in hand, so I can't tell you much how to do that exactly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did more testing this time and even in the emulator there are errors in the raw data, so i don't know if its the device. I used the pl_window flag in 10 to improve the decode speed and indeed it was faster, using less % of the processor, but the error persists.
I attached the raw files and caps of what i see like errors in the signal, and what i think it is the error.
Recording on emulator doesn't look right either, it has zero energy breaks which must be very harmful to accuracy. And the breaks are at 0.15 intervals which correspond to a single buffer allocated in rec_win32.c
Maybe you can try to increase the buffer size WI_BUFSIZE in rec_win32.c to 5000 instead of 2500? also check the actual value of samples read used in ad_read, I wonder should they match with WI_BUFSIZE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First i changed WI_BUFSIZE to 5k, and it did not helped.
Then i tried to put the int32 max value of ad_read matching the 5k i used earlier, but it gave me access violation so i used 4096 on both, but didn't helped.
When i zoom in it seems to me that in the case of the emulator raw data each iteration is moving the signal right a little, not sure what it is yet, im reading the code to understand what is happening.
I appreciate your help,
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been studying the code but i cant find where is the error, as far as i understand so far, changing the WI_BUFSIZE is only affecting the r->curoff value, if you put the WI_BUFFSIZE equal to the samples there is no current offset (in the while(max>0) that starts on line 419 on rec_win32), but nothing changes because it is processed in the next iteration anyway.
I'm trying to understand the code in acmod.c to see if maybe the error lies there, but im running out of ideas. I tested on 2 more computers and the emulator has the same error. Maybe it is an emulator problem and it is not related to my original problem?.
I appreciate your help,
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Nickolay, any updates?
Sorry for the inconvenience.
Sorry, I don't see what is the issue with 08 which is different from 03 and 04. It contains same spikes as before. The picture you attached is a bit irrelevant, you opened file as 32-bit so it is displayed like random noise. When you open raw files make sure you point the proper format 16khz 16bit mono.
That said, I would look to speedup the decoder and make the decoding smoother. It's hard to plan that for me without the device in hand, so I can't tell you much how to do that exactly.
Hello Nickolay,
I did more testing this time and even in the emulator there are errors in the raw data, so i don't know if its the device. I used the pl_window flag in 10 to improve the decode speed and indeed it was faster, using less % of the processor, but the error persists.
I attached the raw files and caps of what i see like errors in the signal, and what i think it is the error.
I appreciate your help,
Thank you.
Last edit: jsrc1115 2014-06-27
Recording on emulator doesn't look right either, it has zero energy breaks which must be very harmful to accuracy. And the breaks are at 0.15 intervals which correspond to a single buffer allocated in rec_win32.c
Maybe you can try to increase the buffer size WI_BUFSIZE in rec_win32.c to 5000 instead of 2500? also check the actual value of samples read used in ad_read, I wonder should they match with WI_BUFSIZE.
Hello Nickolay,
First i changed WI_BUFSIZE to 5k, and it did not helped.
Then i tried to put the int32 max value of ad_read matching the 5k i used earlier, but it gave me access violation so i used 4096 on both, but didn't helped.
When i zoom in it seems to me that in the case of the emulator raw data each iteration is moving the signal right a little, not sure what it is yet, im reading the code to understand what is happening.
I appreciate your help,
Thank you.
I have been studying the code but i cant find where is the error, as far as i understand so far, changing the WI_BUFSIZE is only affecting the r->curoff value, if you put the WI_BUFFSIZE equal to the samples there is no current offset (in the while(max>0) that starts on line 419 on rec_win32), but nothing changes because it is processed in the next iteration anyway.
I'm trying to understand the code in acmod.c to see if maybe the error lies there, but im running out of ideas. I tested on 2 more computers and the emulator has the same error. Maybe it is an emulator problem and it is not related to my original problem?.
I appreciate your help,
Thank you.
Can you record audio in emulator? Is it recorded properly?
Can you record the audio in emulator with sphinxbase ad without recogniton? Is it recorded properly? It's pretty easy to verify the hypothesis
I don't think the issue is in pocketsphinx core, it works fine on many other devices. It must be some wince-specific code.