error initializing audio

[7z3m]

i'm getting the above message mentioned in the title followed by no available audio device when i run ./jackaudio.

im on linux and using alsa only. sound works when playing audio from mpv.

based on the name i assumed jack sound server was a hard dependency, but i see no mention of it. i skimmed through the source code, and will look into it further.

[chvolow24]

@7z3m Hi, thanks for letting me know. Does this occur immediately on startup? If so, seems like the error is occurring here, and the "no audio device" portion of the error is being reported by SDL. Although it seems a little odd that initialization of the audio subsystem would fail with that particular error. What linux distribution are you using, and how did you install SDL (or did you use install.sh)? Can you check the SDL version with sdl2-config --version?

The "jack" in the name is incidental, jackdaw is not jack aware. I think SDL operates at a higher level and ought to work with jack, though.

also, the executable name is "jackdaw" not "jackaudio", but I assume that was just a typo :)

[7z3m]

thank you for responding so fast. yes jackaudio is a typo, but that's not the only stupid mistake i've done - i'm using gentoo and did not enable the opengl and alsa flags. the program is running now, i have some errors in the terminal, but haven't got to test anything yet. you can mark the issue as solved, but just so you know:

Could not validate pd PID Error: unable to retrieve default output device info. That operation is not supported FOUND default device, name ��tU PLAYBACK CONNS: 2 Error: unable to retrieve default input device info. That operation is not supported FOUND default device, name ��tU Error opening audio device ��tU : No such device. Error: failed to open default audio conn " ��tU". More info: No such device. Segmentation fault

the segfault is when i interrupt the program or quit the window, it doesn't crash. ive managed to create a track and import one of my samples, but the program does segfault when i hit the l (play) keybinding, or the j keybinding. i'm gonna play around with the use flags some more, and look into the code further.

*edit: i did not use the install script. i'm used to makefiles, should i have done that?

[chvolow24]

@7z3m Aha, thank you. I think I understand what's going on. Seems like SDL_GetDefaultAudioInfo, which I use to set the default playback and capture audio devices, is not supported on all systems and I was not handling the unsupported case correctly. I can put in a fix with a major upgrade I expect to merge in the next couple days. I'll leave this open for now and will let you know when that goes in.

And no, the bash scripts are just for convenience, however you want to build is fine!

[7z3m]

appreciate that, i've been meaning to migrate my audio production workflow to linux, and this project seems the most promising. i like that there's only the sdl2 dependency, which took very little time to compile.

[chvolow24]

@7z3m that's exciting to hear! Please feel free to contact me anytime with feedback, suggestions, or requests. It's all extremely helpful at this stage. I'm currently unemployed and this project is what I'm spending my time on; you will not be bothering me.

I pushed the update today, so when you get a chance, please rebuild the project and let me know if your issue is fixed in the new version. You will probably need to make clean before you make. The readme also got a significant update and is worth checking out.

[7z3m]

i'm getting better output in terminal, i'm also seeing the imported sample's waveform in the gui, when previously i couldn't. it still segfaults when pressing j/l and i'm getting an overrun error from alsa:

ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.2.12/work/alsa-lib-1.2.12/src/pcm/pcm.c:8750:(snd_pcm_recover) underrun occurred Wav file selected Converting. Len mult: 6 WAV specs: freq: 44100, format: AUDIO_S32LSB, channels: 2 dst specs: freq: 96000, format AUDIO_S16LSB, channels: 2 Len ratio: 1.088435 Segmentation fault

this is the dmesg output:

<6>jackdaw[3948]: segfault at 7f084584f8c8 ip 000055bd4a84ab25 sp 00007f084584e8d0 error 6 in jackdaw[cb25,55bd4a842000+3f000] likely on CPU 0 (core 0, socket 0)

[chvolow24]

@7z3m damn. When you open the program, is a reasonable audio output device found and displayed in the "Output" panel at the top left of the screen, next to "Default Out?"

If you have time, could you make clean, then make debug, run the program with gdb, and send me both the debugger backtrace after the segault occurs and the ASAN output in the terminal? Or the ASAN output alone might be sufficient if you're not familiar with gdb.

[7z3m]

yes actually, i was gonna mention that, it displays all the available sound cards appropriately. and it segfaults no matter which one i use.

i've not done this before, so i had to look it up quickly. i added the -fsanitize=address to the cflags and ran make debug. just so you know i removed the -Wno-unused-command-line-argument as it gave me a note saying its an unrecognized command-line option, and i figured it was taking up unnecessary space.

some of these warnings have been present before during my first time compiling the program, and i should've mentioned it earlier.

debug.txt

unfortunately i dont have gdb installed and when i tried to compile it using my package manager it failed, so i'll have to work on that.

some important info i should've mentioned earlier also, is that im using musl libc.

[chvolow24]

@7z3m make debug includes -fsanitize=address automatically (it's in the CFLAGS_DEBUG variable), so you shouldn't need to alter the makefile. I don't think any of those compiler warnings in the file you sent are the cause of this (though I really should fix them).

What that fsanitize flag ought to do is cause the program to print a bunch of helpful extra information when a memory error occurs. So the output I'm referring to should show up when the program segfaults. Are you seeing any of that?

One other thing that might be worth trying is to swap out gcc on the first line of the makefile for clang.

I wasn't familiar with musl libc, but I assume if there was some function implementation missing that'd show up as a linker error, so probably shouldn't be the cause.

[7z3m]

ok, i understand, hope this helps

AddressSanitizer:DEADLYSIGNAL

==1831==ERROR: AddressSanitizer: stack-overflow on address 0x7fb34768d3d8 (pc 0x55f039d7268e bp 0x7fb347692500 sp 0x7fb34768c3e0 T10)

0 0x55f039d7268e in FFT_inner src/dsp.c:95

#1 0x55f039d728fa in FFT src/dsp.c:108
#2 0x55f039dba184 in transport_dsp_thread_fn src/transport.c:243
#3 0x7fb34d5c6d75  (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x53d75)

SUMMARY: AddressSanitizer: stack-overflow src/dsp.c:95 in FFT_inner Thread T10 created by T0 here:

0 0x7fb34d67ff70 in pthread_create (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x10cf70)

#1 0x55f039dbb030 in transport_start_playback src/transport.c:348
#2 0x55f039dc68b1 in user_tl_rewind src/userfn.c:627
#3 0x55f039dad9dc in loop_project_main src/project_loop.c:351
#4 0x55f039d7c959 in main src/main.c:316
#5 0x7fb34dcb854a  (/lib/ld-musl-x86_64.so.1+0x4554a)

==1831==ABORTING

[chvolow24]

that's very helpful! it seems your system has a smaller default thread stack than either of the ones I test on, and my FFT implementation is causing stack overflow. I can probably fix this, but it might take a couple days -- I'll let you know.

[7z3m]

that's interesting, i was under the impression that linux had a sizeable default thread stack being 8MB. running ulimit shows mine is no different.

[chvolow24]

@7z3m I think the 8MB displayed by ulimit might apply to the main thread only. I just pushed an update that explicitly sets the stack size for the thread on which this is occurring. Can you check to see if that fixes the issue?

[7z3m]

this fixed the issue. i just opened up a project and played around with some samples then saved the project successfully. i received a memory leak on exit though, and i think that same issue prevented the saved project from opening back up again.

this is the error when i quit the project

==2968==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 960000 byte(s) in 2 object(s) allocated from:

0 0x7fec9b33e417 in malloc (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x115417)

#1 0x55a979499cf1 in wav_load_to_track src/wav.c:226
#2 0x55a979482746 in openfile_file_select_action src/userfn.c:324
#3 0x55a9794a8d32 in dirnav_select gui/src/dir.c:544
#4 0x55a9794a90ab in dirnav_triage_click gui/src/dir.c:554
#5 0x55a9794c7d56 in modal_triage_mouse gui/src/modal.c:576
#6 0x55a979440057 in mouse_triage_click_modal src/mouse.c:236
#7 0x55a97946d113 in loop_project_main src/project_loop.c:482
#8 0x55a97943ba2e in main src/main.c:316
#9 0x7fec9b96e54a  (/lib/ld-musl-x86_64.so.1+0x4554a)

Direct leak of 29344 byte(s) in 262 object(s) allocated from:

0 0x7fec9b33e7b0 in calloc (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x1157b0)

#1 0x7fec9b0f3735  (/lib/libSDL2-2.0.so.0+0xa6735)

Direct leak of 184 byte(s) in 1 object(s) allocated from:

0 0x7fec9b33e7b0 in calloc (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x1157b0)

#1 0x55a97941edf2 in query_audio_connections (/home/hazem/jackdaw-main/jackdaw+0x18df2)

Direct leak of 184 byte(s) in 1 object(s) allocated from:

0 0x7fec9b33e7b0 in calloc (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x1157b0)

#1 0x55a97941ec60 in query_audio_connections (/home/hazem/jackdaw-main/jackdaw+0x18c60)

Indirect leak of 6812 byte(s) in 262 object(s) allocated from:

0 0x7fec9b33e417 in malloc (/usr/lib/gcc/x86_64-pc-linux-musl/14/libasan.so.8+0x115417)

#1 0x7fec9b0f376e  (/lib/libSDL2-2.0.so.0+0xa676e)

SUMMARY: AddressSanitizer: 996524 byte(s) leaked in 528 allocation(s).

and this is when i try to open the saved project by using ./jackdaw project.jdaw

Error opening unpause sem: File exists Error opening readable chunks sem: File exists Error opening writable chunks sem: File exists AddressSanitizer:DEADLYSIGNAL

==3471==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000188c (pc 0x55d844e2f93c bp 0x7ffd7076f290 sp 0x7ffd7076f280 T0) ==3471==The signal is caused by a READ memory access.

0 0x55d844e2f93c in delay_line_init src/dsp.c:577

#1 0x55d844e2c252 in jdaw_read_file (/home/hazem/jackdaw-main/jackdaw+0x2b252)
#2 0x30454e494c454d48  (<unknown module>)

AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV src/dsp.c:577 in delay_line_init ==3471==ABORTING

i'm also still getting "underrun occured" from alsa as i'm using the program.

let me know if i cant help you any further, still loving this project now that i can put in some sounds and play around with it.

[chvolow24]

@7z3m progress! I just put in some fixes -- let me know if those eliminate some of these issues. The project file you saved already should be valid, so I think you'll be able to open it without issue now.

I have no idea about the alsa underrun error to be honest.

Also, some leaks may still be reported by ASAN, but they are not necessarily cause for concern. I've noticed that SDL's main allocator function causes a leak report, but that is almost certainly spurious.

[7z3m]

ok, i just opened the existing project successfully, and closed it, and as you said i had some memory leak errors(1). the second time i did some recording and on save it seemed to crash with some errors(2). then it failed to open with a hefty amount of memory leak errors, thats just a part of it (3).

debug_1.txt debug_2.txt debug_3.txt

i believe this is related to recording, since it crashed later with similar errors as in debug_2.txt as i was testing the record function, but worked fine without recording.

[chvolow24]

@7z3m sorry for all the errors, and thanks very much for working through them with me.

Aside from one new leak that I've now fixed (which I had introduced when I was fixing the first issue you encountered), the memory leaks in debug_1.txt and debug_3.txt suggest that the quit routine is somehow not being called or not completing execution when the program exits, since all of those memory objects are freed in the course of that routine. When you go to exit the program, do you see the "Really quit?" dialogue box? How are you quitting (window "X" button, ctrl-q, some other way)?

I am also mystified by the crash in debug_2.txt. I'm looking into possible causes, but in the meantime: have you ever been able to successfully record a clip and play it back, and did it sound normal? Are the problems the same no matter which audio device you choose (if you have several to test with)?

[7z3m]

i just tried again, and it ran perfectly and re-opened. what i'm doing is placing a kick and a snare on two separate tracks, and recording the master output on a third track as i mess around with the rewind and play buttons. i didn't spend a lot of time fiddling around though, i'm gonna try and do that tomorrow.

the first attempt was inside the first project i created from the previous versions of the program, it saved just fine, with the dialogue popping up and everything, it just would show errors when i tried to open it up again. i used ctrl-q.

the second attempt was in a new project, but for whatever reason, it just wouldn't record the output from the master on that third track, and in my clicking around it crashed.

what a great idea this daw, really impressive. how do you operate without a grid/time signature?

[chvolow24]

@7z3m weird. well, I hope it keeps running smoothly, but if you get more crashes, please let me know.

If things continue running well, you may want to make clean and then make (without debug) at some point, since the debug version of the program is not optimized and will run quite a bit slower.

Thank you for the kind words! I'm glad to hear you're messing around with the "Jackdaw out" feature, that's a fun one. Make sure you give S-<scroll> and C-S-<scroll> (to adjust the play speed) a try at some point too, those go well with that feature. The grid/time signature is simply one of many features I haven't implemented yet, but my current plan is to hit that one next!

[7z3m]

i like the sparsity of features, i would say it's 99% done. something like podcast editing would work perfectly on this.

i see you're working on an eq though, that's definitely a key feature for music making and sound design. it would be super cool if there was something like a config.h file with:

static Feature defconfig[FeatureLast] = {
    /* features                               Arg value*/
    [EQ]                              =       { .i = 1 },
    [ADSR]                         =       { .i = 0 },
};

that way you can have a tiny featureless and efficient program that take little time to compile for basic audio editing, and it would open the door for more features/plugins to be added by users based on their needs.

the config file could have color scheme/font also

static char *font = "terminus:pixelsize=32:style=normal:antialias=false:autohint=false";

static const char *colorname[] = {
    [0]  = "#121212",
    [1]  = "#777777",
        .....
},

i don't know how that would fair in terms of portability, which i know is something you have in mind. and i'm not sure how open macos users would be to compiling and recompiling their daws.

[chvolow24]

@7z3m I definitely like the idea of text-editable user configs! I've also considered providing an API such that users can write their own programs that directly modify jackdaw parameters. But I've got a lot of more basic features that I probably want to hit first, so it might be a while. Right now, the very rough road map is:

• tempo, time signature, metronome etc.
• mono audio tracks
• support audio devices with >2 input channels
• parametric EQ, compressor, reverb, other effects
• looping
• MIDI support, and...
• VST support, and/or...
• built-in synthesizer, and/or...
• more robust pure data integration
• "timeline reference", which is a clip-like reference to one timeline placed on a track in a different timeline (would be unique to jackdaw, as far as I know)
• mixing abstractions like buses and sends

I expect this all could six months to a year or more. But we'll see.

I'll close this for now, but please feel free to create a new issue (or reopen this one) if you run into any more bugs. And email me anytime for suggestions or feedback, it's all welcome. Thanks again for all your help!

[7z3m]

hey, i spent some time putting together some drums, 4 tracks, got done with 1/2 bars and it crashed on me. this is the debug message, i think its similar to that of debug_2.txt

debug_4.txt

i was surprised at how little of an effect the grid has, i pretty much had no problem laying things out on time. again loving this, never expected i'd be doing something like that in linux.

idk if you got my email btw, i think its some cool stuff that might help you with the music making. i sent it a few days ago.

[chvolow24]

@7z3m thanks! Took me a minute to figure out what was causing this but I can replicate it now. I think it should be a quick fix but I dropped it in a new issue just in case I need to track it. I'll let you know when I get a fix in.

I've heard that burial never quantized anything, so if you ditch the grid you'll be in good company :)

and thank you for the heads up on your email, it landed in my spam folder! will respond there

[chvolow24]

@7z3m ok the cause of debug_4.txt should be fixed. I'm still not sure about debug_2.txt