#trinity-desktop < 2026/05/24 >
[00:27]magnus__6 has quit (Quit: Konversation terminated!)
[02:15]agneli has quit (Remote host closed the connection)
[02:30]agneli has joined
[07:19]Fat-Zer has quit (Ping timeout: 245 seconds)
[07:32]Fat-Zer has joined
[09:05]neoncortex has quit (Quit: ZNC 1.9.1+deb2+b3 - https://znc.in)
[10:05]Fat-Zer has quit (Quit: KVIrc 5.2.10 Quasar http://www.kvirc.net/)
[10:05]Fat-Zer has joined
[10:18]SlavekB: ceux, I updated the package to the current GIT state and I get:
[10:19]SlavekB: [2026/05/24 12:15:58.933] [4172777] ERROR: KUniqueApplication: Registering failed!
[10:19]SlavekB: [2026/05/24 12:15:58.933] [4172777] ERROR: Communication problem with tmix, it probably crashed.
[10:20]SlavekB: [2026/05/24 12:20:15.342] [dcopserver] DCOP aborting call from 'anonymous-4175894' to 'tmix'
[10:26]SlavekB: When I reverted back to version ~pre22, running tmix was no problem.
[11:31]SlavekB has quit (Quit: Kopete 0.12.7 : http://trinitydesktop.org)
[12:58]magnus-6 has joined
[13:15]a-865 has quit (Quit: ChatZilla 0.24b1pre [SeaMonkey 2.53.24/20260217210227])
[13:39]magnus-6 has quit (Remote host closed the connection)
[13:49]micheleC has joined
[13:51]micheleC: @ceux: tqt3 network stack is not too bad, it is just imcomplete/basic. Qt4 definitely provide a more modern interface.
[14:03]ceux: SlavekB... hum!
[14:03]ceux: micheleC: you will find me in favor of just dropping code as much as possible
[14:03]ceux: fairly certain theres a bug in the qt ftp stack where you could inject commands from a nastily named filename, i want to test it but havent written a poc but i think theres an issue
[14:10]micheleC: (y)
[14:30]ceux: this is weird, this tmix failure is aroudn registering it
[14:30]ceux: the only change on that commit is to the TDEUniqueapplication.h
[14:31]ceux: which is what does the registration
[14:36]micheleC has quit (Read error: Connection reset by peer)
[14:38]SlavekB has joined
[14:52]ceux: SlavekB: fixed it.
[14:52]ceux: when i flipped it to TDEUniqueApplication.h i lost a extra !.
[14:56]ceux: SlavekB: though that error message i think is weird,... it should say TDEUniqueApplication if you are against master.
[14:56]ceux: 271 kdError() << "TDEUniqueApplication: Registering failed!" << endl;
[14:58]SlavekB: I am using PSB - i.e. r14.1.x branch.
[14:59]ceux: i see
[14:59]ceux: the issue was - if ( TDEUniqueApplication::start() )
[14:59]ceux: + if (! TDEUniqueApplication::start() )
[15:00]SlavekB: Sure, that makes sense. I'll make new builds.
[15:02]a-865 has joined
[16:49]SlavekB: Ceux, now it's fine - the application is running. Currently tested on my PineBookPro, where I currently have 4 audio outputs, so good for testing.
[16:51]SlavekB: When I tried to switch to the OSS backend, a crash occurred.
[16:53]ceux: ok thank you. it could just be something where i try to open /dev/mixer
[16:56]ceux: reproduced. did it crash or just get stick, i can reproduce it getting stuck because its waiting to open something and then newer redraws anything.
[17:04]SlavekB: When I switched, the application disappeared. When I started it again, it crashed.
[17:04]SlavekB: I had to manually edit the configuration file to get the application to run again.
[17:05]ceux: yes exactly. i am working on a fix
[17:05]ceux: basically we just try to open but it doesnt wokr without oss.
[17:05]SlavekB: (Y)
[17:05]ceux: instead we should draw the screen and return an error message
[17:05]ceux: There could be an OSS users who cannot open it (example, not in audio group)
[17:05]ceux: should give a relevant result.
[18:22]agneli has quit (Remote host closed the connection)
[18:27]agneli has joined
[19:00]agneli has quit (Remote host closed the connection)
[19:10]agneli has joined
[21:34]ceux: SlavekB: fixed & pushed.
[21:52]SlavekB: The build of the updated packages will start shortly.
[22:09]agneli has quit (Remote host closed the connection)
[22:11]SlavekB has quit (Quit: Kopete 0.12.7 : http://trinitydesktop.org)
[22:14]agneli has joined
[22:33]neoncortex has joined
[22:50]SlavekB has joined
[23:19]ceux: SlavekB: good. this can also be tested with the alsa oss modules if you have them
[23:19]ceux: modprobe snd_mixer_oss
[23:24]SlavekB: Back on the desktop machine I tested Pulse, Alsa and OSS. Everything here shows something.
[23:24]ceux: well that is a step indeed.
[23:24]ceux: i dont know anyone who has bsd other than denk so he will need to test on an actual card
[23:25]SlavekB: In any case, the playback level display in the output device meter is delayed by about 1:10 seconds from the start of playback.
[23:25]ceux: on which? pulse?
[23:25]SlavekB: Pulse.
[23:25]ceux: there is a builtin decay
[23:25]ceux: 1 to 10 seconds or 0.1 seconds
[23:26]SlavekB: So it looks a bit funny when the indicator for Amarok shows, but the device indicator as such is "silent".
[23:26]SlavekB: After about 1:10 seconds it started to show.
[23:27]ceux: i do not understand i am sorry
[23:27]SlavekB: Conversely, after the playback ends, the Amarok indicator is "silent", but the device indicator still shows, even though it is actually silent.
[23:27]ceux: between 1 and up to 10 seconds?
[23:27]SlavekB: No, one minute and ten seconds.
[23:28]ceux: a minute and ten seconds! holy smok
[23:28]ceux: yeah i see a delay here as well. Maybe we are 'behind' in our polling and just need to discard...
[23:28]SlavekB: That's right, it's delayed by more than a minute.
[23:28]ceux: the polling loop should not be doing much while the mixer is not open, but pulse will still fire the event loop.
[23:31]SlavekB: That's why it looks very funny, because it's really impossible not to notice for more than a minute.
[23:32]SlavekB: I was also surprised for a moment when the tray icon showed that recording was active - it said that arts was recording.
[23:32]SlavekB: And it seemed that at that moment the icon did not react to anything at all.
[23:34]SlavekB: I wanted to look at the mixer window, but since the menu on right click wouldn't open, I couldn't look.
[23:34]SlavekB: When the recording icon disappeared, I could look at the mixer window again, but there was nothing to see there anymore.
[23:34]ceux: was artsd recording? humm
[23:35]ceux: well weird ok interesting behaviour certainly.
[23:35]ceux: i see playback in the main mixer window almost immediately
[23:35]ceux: on pause it takes a bit to go down. the delay may be too slow.
[23:36]SlavekB: Now I look in the mixer window and see that the playback level for the device is showing something, even though it's been many minutes since Amarok finished playing and nothing else is currently playing.
[23:37]ceux: SlavekB: well i can certainly reproduce the main audio not showing anything when amarok is playing. there must be some issus in here.
[23:38]ceux: yes i see there is a bug i think its a stupid one. let me investigate.
[23:38]ceux: thanks
[23:38]SlavekB: Interesting - Kopete through arts now played a notification sound when you mentioned me and at that moment I see the icon again that said arts was recording.
[23:38]ceux: how does arts work? does it fake a microphone or something odd
[23:41]ceux: SlavekB: i can reproduce that artsd shows up, when i play a noise (say from twin) but not as a recording device.
[23:42]SlavekB: I just changed some sound server settings in Trinity Control Center and when artsd restarted, it immediately showed the recording icon.
[23:42]ceux: intersting. what about with like artsplay
[23:43]SlavekB: And while artsd was waiting to leave the device, it showed the recording icon.
[23:43]ceux: SlavekB: one important way to test is to also have pavucontrol open. do you have that as well?
[23:44]SlavekB: I have it installed... wait a minute, I'll take a look.
[23:46]SlavekB: In pavucontrol I see two tmix entries (tmix-peak) as recording and at the time artsd was also active on the device, it was also on the list.
[23:46]ceux: yes.
[23:47]ceux: you will also see that one tmix, that pavucontrol-qt is listening
[23:47]ceux: because it's doing a peak detection
[23:47]ceux: ok so if you see artsd recording on pavucontrol... that is what it is.
[23:47]ceux: unless we should maybe hardcode remove artsd
[23:48]ceux: SlavekB: sweet, I got it to happen. thanks
[23:48]SlavekB: Yes, now, on the contrary, I see two recording items from pavucontrol in tmux and also a recording icon in the tray.
[23:48]ceux: yes. that makes sense.
[23:48]ceux: just is the nature of the beast, unless we have a way to see if its a peakstream. will need to investiage.
[23:49]ceux: mostly first i need to get these peak meters cleaned up and working correctly. removing the delay/attack code didn't improve it so it must be something before setLevel.
[23:50]SlavekB: When the recording from artsd is displayed, a third item for peak detection will be added => tmix item in pavucontrol / pavucontrol item in tmix.
[23:53]SlavekB: BTW, the Open Mixer menu item could work similarly to how it does in kmix - when the mixer window is open, it would change to Close Mixer.
[23:54]ceux: good idea. also i added "Open Devices" which is opens the devices tab directly for pavu, but open mixer then if it is on devices will stay on devices...
[23:55]ceux: 'fiddly bits'
[23:55]SlavekB: A mute menu item like in kmix could also be useful.
[23:56]SlavekB: When I tested whether the middle button would open the mixer window, like I have in kmix, I didn't see any reaction.
[23:58]ceux: middle click mutes/unmutes
[23:58]ceux: i thought that would useful to do _fast_
[23:59]SlavekB: Then I noticed in the settings that it was possible to set the middle button to mute, which I had turned off.
[23:59]ceux: i see. well. we could do a whole 'map this button to that' exercise in configuration but... idk

#trinity-desktop < 2026/05/24 >