I am trying to use pocketsphinx as part of a c++ program and have a problem when running my code. I had two issues: The first being that my microphone wasn't being recognized by pocketsphinx and the second being a seg fault when ps_start_utt was called. I'm running this on ubuntu 14.04. Here is the original code:
ps_decoder_t *ps;
cmd_ln_t *config;
ad_rec_t *ad;
config = cmd_ln_init(NULL, ps_args(), TRUE,
"-hmm", "/usr/local/share/pocketsphinx/model/en-us/en-us",
"-lm", "../audio/1638.lm",
"-dict", "../audio/1638.dic",
"-logfn", "/dev/null",
NULL);
ps = ps_init(config);
ad = ad_open_dev("sysdefault", (int) cmd_ln_float32_r(config, "-samprate"));
// below is the other thing I tried to use to open the audio device.
// ad = ad_open();
cout << "AAAA" << endl;
ad_start_rec(ad);
cout << "BBBB" << endl;
ps_start_utt(ps);
cout << "CCCC" << endl;
utt_started = FALSE;
When executed, this produced two errors at the command line. The first was an error about being unable to find the sysdefault audio device and the second was a seg fault that occurred after AAAA and BBBB were outputted (CCCC was never printed).
This means that something in ps_start_utt is causing a seg fault but I have no idea what. I originally thought the two errors were related so I tried to fix the first one. By replacing the string sysdefault with NULL in ad_open_dev the first error no longer appears but the seg fault still happens.
Using ad_open() instead of ad_open_dev is the same as substituting NULL; the first error is no longer present but the seg fault still occurs in the same place. However, the strangest thing to me about this issues is that the pocketsphinx_continuous -inmic yes command works perfectly on the same machine with the same mic. I have looked at the continuous.c code on the cmusphinx repository but haven't been able to figure out what the difference is or how I might correct it. I can post more of the code if necessary. Any help would be greatly appreciated!
UPDATE: After doing some checks I found that the error that causes the seg fault is that ps == NULL. I'm still not sure why this would be happening however.
Related
I got an error while debuging a program i wrote down from a tutorial online, it is a sound synth made by the one lone coder on youtube. I'm not sure what caused it or how to fix it. I disabled pre-compiled headers witch was the first problem i encounterd.
I have tried searching online, leading me here to awnsers about code of others, i have tried going on multiple discord servers and asking there.
No luck so far. Also this is just as a little exercise to help me get back on track.
Main.cpp
#include <iostream>
#include "olcNoiseMaker.h"
using namespace std;
double MakeNoise(double dTime) {
return 0.5 * sin(540.0 * 2 * 3.14159 * dTime);
}
int main() {
wcout << "onelonecoder.com - synth part 1" << endl;
//Get all sound hardware
vector<wstring> devices = olcNoiseMaker<short>::Enumerate();
//Display finding
for (auto d : devices) wcout << "Found output device:" << d << endl;
//Create sound machine
olcNoiseMaker<short> sound(devices[0], 44100, 1, 8, 512);
//Link noise function whit machine
sound.SetUserFunction(MakeNoise);
return 0;
}
olcNoiseMaker.h is just to get acces to the sound chip and bla bla.
you can see his video here: https://www.youtube.com/watch?v=tgamhuQnOkM&t=134s
Running the program should result in a contenious sine wave of 540 KHz
instead it plays it only once and gives me this error:
Unhandled exception thrown: write access violation.
_Tgt was 0xA4EFF82C. occurred
Late to answer, but I had this issue (Visual Studio 2019). When I built and ran the program, there was just one short beep before the program exited. The issue was that I was in the x64 Debug configuration, and that was causing the error. Once I changed to x86 Debug, it was working perfectly.
Edit: Also, in your code, you are missing the while(1) {} after the sound.SetUserFunction(MakeNoise); statement which would be needed to get the code working according to the video.
Using CodeLite c++14, mingw-32. I'm fairly new and learning from a course to program in the languge, but i've encounterd a problem in the last couple of days i couldn't figure out. For some reason, the command line prompt shows only the last row of my output code. this happens in all types of code that i've done so far.
Something that might be connected is that sometimes on the first building & executing of code (after a clean) i'm getting an error:
mingw32-make.exe: *** [All] Error 2
It's just an inconvinice though, a second build is solving this problem for some reason. But it might be connected some how.
Any way here's an example for a code:
#include <iostream>
using std::cout;
using std::cin;
using std::endl;
int main() {
char vowels[] {'a','e','i','o','u'};
cout << "\nThe first vowel is " << vowels[0] << endl;
cout << "\nThe last vowel is " << vowels[4] << endl;
return 0;
}
The output that shows is only "The last vowel is u", it goes to basiclly any code i create.
Thanks!
So I found an answer, and this probably won't help alot of people because its pretty absurd. apperantly i had a mining virus on the computer which also made it so at startup only a CMD window would appear and I had to type 'explorer.exe' manually.
So mingw basiclly tried to tell me something was messing with my CMD every time i opened it. What a way to find out.
A fix for those who face the same (found on reddit #spiralspectra):
1.a) Open Run (windows key + r) and enter "%appdata%" without quotes and press enter.
1.b) Go to the Microsoft folder and delete the SoundMixer folder contained within (This is the mining software).
1.c) Open Run and enter "regedit.exe" without quotes.
1.d) Find the registry entry mentioned as([HKEY_CURRENT_USER\Software\Microsoft\Command Processor]) and remove it. This entry attempts to run the miner whenever a CMD is started.
2.a) Go to the winlogon registry entry in the same regedit software ([HKEY_CURRENT_USER\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon])
2.b) Check the sub-key named "shell" and change its value to "explorer.exe" without the quotes. (This means when you log onto windows it will no longer attempt to run the miner and instead start up normally.)
I am new to using GDAL, and am having trouble creating a GDALDataset using the GDALDriver::Create() method. In this case, I am using C++. Ultimately I am trying to create a raster and write values from an array to the raster. A minimal working example of the code that generates the problem of creating a dataset is given here:
#include <iostream>
#include </usr/include/gdal/gdal_priv.h>
int main(){
std::cout << "starting GDAL business\n";
const char *raster_format = "GTiff";
GDALDriver *g_driver;
g_driver = GetGDALDriverManager()->GetDriverByName(raster_format);
GDALDataset *g_dataset;
const char *test_file = "test_file.tif";
char **raster_creation_options = NULL;
std::cout << "raster options created\n";
g_dataset = g_driver->Create(test_file,
100,200,1,GDT_Float32,
raster_creation_options); //<--- seg faults
std::cout << "dataset created\n";
}
The resulting console looks like:
starting GDAL business
raster options created
Segmentation fault (core dumped)
I am just following the basic API tutorial (Link), but am encountering this problem. I am on Ubuntu 14.04, using the repository's libgdal packages.
Can anyone shed some light on this problem?
I know this is an old question and the issue has probably long since been resolved, but I figured I would throw my answer into the ring. After all, I was directed here when I had this problem and it seems like the question has a fair amount of views.
If your code is not working, and you are having trouble loading the driver, I would suggest adding the line GDALAllRegister();. I was following the same tutorial as you, and they mention adding this line at the top of the tutorial, but if you're like my and rushed right to the part you needed, the Create part of the tutorial, you probably overlooked that step.
Hopefully this answer helps someone, if not the original author of the question.
I have a program written in C++ that uses a lot the "system" function to run things like i would run in Shell (using Ubuntu 12.04 32 bits).
The things done in the "system" function generate several files that will be processed. In a second part of the program i process those files.
When the program ends, it doesn't delete those files that was generated by the "system" functions.
When i run the program for the first time it runs fine, when i run in a second time it gives me Segmentation fault (core dumped) in a given loop of the second part. It does less iterations each time i try to run. For example : First run = ran fine. Second run = Segmentation fault(core dumped) in iteration 200. Third run = Segmentation fault(core dumped) in iteration 199. And goes on...
I resolved the problem deleting all files it had generated by "system" function in the end of each "run" of the program.
My question is...any one has any clue about why was it happening?
EDIT*
Below is a few pseudocode to exemplify.....unfortunately i cant put the entire code, its like 600 lines.
int main(void){
// Part 1 of the program.....severam "system" producing files
system("bash produceSeveralFiles.sh");
// Part 2 of the program......process files produced in part 1
processFiles();
// My Solution that i dont know why solves it
system("rm AllFiles");
return 0;
}
EDIT*
Way i checked that it goes until the loop...
for(int i = 0; i < 300 ; i++){
printf("\n%d",i);
...//a few code here
printf("\n%d",i);
}
Second run i see "i" goes until 200....third run i see "i" goes until 199....and go on...thats the way i checked where it was giving the Segmentation Core (dumped).
EDIT*
O well im ashamed now, just checked the old Script that was generating the files before the program and it gives the same problem....if i do the generation in a separated file and then only runs the "processFiles()" in the program, it gives the same error. The old Script has an "rm files" command in the end that wasnt concerned about. (thx to user #beta....just checked the old script cause your commentary)
Well....but anyway the question continue, but now i know its not only with the "system" function.
I have a "black box" question about an error I get when I run a discrete event simulation for about a minute. Everything works fine, and it completes successfully, but the system prints the following message once at some point during the simulation:
Error (202): Command token too long
I've never seen anything like it. I wonder what "command" it's referring to. Perhaps it's system("...") call that I make several times in the program in order to plot and visualize the data it generates.
I'm sorry I can't provide any code as I'm not sure where the error is coming from. Is there an efficient way to discover at which point the system generates this message? Or in any case, have you encountered such an error in your own C++ programming experience, and thus suggest where it could possibly be coming from?
I'm using Ubuntu 11.04 and compiling with GCC. The error appears at run-time during the simulation for simulations that are especially long (30+ seconds), and doesn't appear in shorter cases. I should emphasize that the "error" doesn't stop the execution of the code and doesn't actually cause any visible errors in the visual output of the simulation data.
write a program similar to the following:
int trials 10000;
string str("ls ");
while( trials--)
{
system( str.c_str() );
str += "a";
cout << "chars in cmd = " << trials << endl;
}
It will successively run commands like
ls, ls a, ls aa, ls aaa, while simultaneously printing to the console what trial # it's on.
and if you're right about where the error is coming from, eventually it will get the same error message about "token too long", and if so, tell you how many characters the cmd may be. Then code this limit into your real C++ program so that it doesn't emit the error.
If it doesn't reproduce the error, try making # trials bigger, say up to 100k. If it still doesn't happen, the error is probably coming from somewhere else.
It's coming from a lexer, telling you that one of the tokens (identifiers/preproc tokens/etc.) in your program is rather lengthy. Look through your code to see if there are any ridiculously long strings or preprocessor tokens.