![]() |
|
Using Linux has inspired me to learn C and here's my MORSE program - Printable Version +- Linux Lite Forums (https://dfgkh547-jsdfv8.iyhkj.tk/forums) +-- Forum: Development (https://dfgkh547-jsdfv8.iyhkj.tk/forums/forumdisplay.php?fid=7) +--- Forum: Coding (https://dfgkh547-jsdfv8.iyhkj.tk/forums/forumdisplay.php?fid=33) +--- Thread: Using Linux has inspired me to learn C and here's my MORSE program (/showthread.php?tid=5142) |
Using Linux has inspired me to learn C and here's my MORSE program - alowe - 04-02-2018 Something about using Linux encourages me to learn C. So I wrote a simple program to output morse code. I wanted it to play the morse a bit faster but if I reduce the sample lengths any further they fail to play at all. So this looks like it's as far as it will go. Never intended for it to be practical. Just wanted to try something. I'm not sure if attaching Linux executables is safe or advisable (it isn't on Windows systems). Incase it doesn't work or you want to compile it yourself, here is the code: Code: // Compilation:I can see things that could be improved but resisting the urge to tinker further. E.g. reveal should still work even if the audio driver fails to load and the final return doesn't need a ternary operator. Must resist urge to tinker... Expected output: Code: Usage: morse [opt] [text]Any number of options can be given in any order. If using audio, the morse is played slowly enough that you can learn how to recognise the sounds. If you wanted to use it to play fast morse I guess you could sample the raw output into something like Audacity and then speed it up without raising the pitch. If your device doesn't support direct sampling internally then just use a male to male audio jack between the microphone and headphone inputs. Does the job. Edit: Have attached an example.mp3 file to show what that the following message sounds like when sped up in Audacity: "Example of output from the morse program" Re: Using Linux has inspired me to learn C and here's my MORSE program - bitsnpcs - 04-03-2018 [member=5997]bluzeo[/member] was looking for Morse software recently. Re: Using Linux has inspired me to learn C and here's my MORSE program - Wirezfree - 04-03-2018 Maybe us Radio Amatuers should start a "LL NET" ![]() 73 - G8LIY Re: Using Linux has inspired me to learn C and here's my MORSE program - alowe - 04-04-2018 I've just noticed some more "bugs" in the program. There should be a constant delay between dots and dashes in the audio output, but looking at the sample this is not the case. I think this is because the sample sent to libao does not pause execution inside the C program. There are two solutions to this: 1) Calculate an additional time to wait and add it to the delay sent to usleep(); e.g. usleep(delay + (<dot or dash> * 1000)); 2) Have a loop that polls libao for some finished state. Personally I like solution 1) because, it's easier to implement, requires less reading about libao and relies less on the behaviour of software outside of the morse program (e.g. if libao never returns finish, what to do? complicated). Then again solution 1) is also complicated because the time it takes to play a dot or dash is based on other things like the sample rate. There's also something not right about the sound recorded by Audacity. This shows that at the end of the sample the output is left high when it should be left low, which looks ugly and I think makes "ticking" more likely if/when the sample is interrupted. Since the human ear (and computer speaker) function by changes in movement from down to up and up to down, this makes no difference to the sound you hear. It just looks ugly. There's also a slight issue if the C program is forcefully halted by something like a Ctrl-C. Even though I've put code to cleanly close and shutdown the ao device, this will not get executed if the program is halted externally. The OS might be clever and do this upon detecting the executable that opened the device has been forcefully halted. It may not. I'm not sure there is a C solution to this (i.e. a function that gets executed upon a forceful halt). Maybe I could fork off a TSR process in memory that monitors the existence of the morse executable process and cleanly shuts down the ao device if it stops running. That's complicated and may introduce further problems. I've tested forcing the program to halt without closing the ao device and this doesn't effect sound output from other programs or future executions of morse. So this might just be me worrying about nothing. If I ever go back to improve this morse program I will fix all of these things (including the tweaking). |