Development 2.0

[SamDel]

@FA-Bubba & @GrahamDLL

Let's discuss 2.0 development here.

[SamDel]

Ideas from the 1.9 branch, and some (wild) new ideas:

• Option - Automatically start when Windows starts
• Countdown when restarting
• Help texts in the user interface
• Application Name - "xxxxx - Desktop Audio Streamer"
• Option to filter devices, show 'All', 'Devices only', 'Groups only'
• Option to load a web stream directly on a device/group (Radio Paradise)
• Resizable user interface
• Themes?
• "Start last used devices or groups" option
• Keep an application buffer to start streams faster (and maybe to avoid dropouts)
• Stabilize connections and automatic restarts/recoveries
• Improve Error handling

[GrahamDLL]

I would be content if "Start when Windows starts" was in the installer and not an option in the app.

My vote would be to keep the "Desktop Streamer" as is ... There are already a gazillion apps that play Internet radio and upnp/dlna streams and all that ... A separate app "Desktop Streamer Plus" perhaps?

I have devices that are upnp/dlna receivers ... I use Chromecast to stream to them because I can group Chromecast and I can't (that I know of) group upnp/dlna devices. One possible development would be to add support for upnp/dlna devices.

[FA-Bubba]

For what it's worth...
I would prefer "Start when Windows starts" remain as an option in the app, because I may not always want the same action. Most other Apps I use that have this as a choice have it in an "Options" section that can be changed anytime.

[GrahamDLL]

My mistake ... I meant to say ... I would be content if "Start when Windows starts" was an option in the installer and not an option in the app ... The ideal solution is to have an option in the app.

[SamDel]

I've added "Start last used devices or groups" to the list, that's a nice one! Only the devices that where playing when the application was closed for the last time will be restarted. For "Start when Windows starts" I will only make an option in the application. Adding an option to the installer was too much work (that wasn't clear in my previous comment).

wikijm added the translations for the new labels in 1.9.xx, so we're almost ready for a 2.0 release, don't you think?

[GrahamDLL]

The only part of 1.9.xx that is still not reliable seems to be the automatic start of devices. Is that coming out of 2.0 because automatic start of last used devices will be added in a future version?

[SamDel]

I don't know what goes wrong there for you, for me it works every time.
The failing (random) device sends a 'load failed' message when it tries to load the stream. Can be a resource problem. Is the CPU or memory at 100%?
Maybe we find out later, or try to fix it in 2.0. Have you tried, @FA-Bubba ?

[GrahamDLL]

Can be a resource problem. Is the CPU or memory at 100%?

Could be ... it's a pretty pathetic little computer ... I'll look at CPU and memory use tomorrow.

[FA-Bubba]

@SamDel: I've been traveling, and haven't tried anything since Monday...
I believe I was using v1.9.65, and the only issues I experienced were various speakers dropping off line, with some automatically coming back on line.

I'll load the current version on Friday -- what are any particular actions you want me to try?

[SamDel]

I've created a new issue for this, and added it to the 2.0 project.

@FA-Bubba : check the 'Automatically start devices at startup' option and restarting the application. All devices should start, for @GrahamDLL some (random) devices give a load failed error.

[GrahamDLL]

I am guessing that I accidentally ran V2 yesterday when I got an exception when using automatically restart last used group. You commented that this might be because of a delay in the start of the "speaker" that is being captured.

The "speaker" that I capture with Desktop Streamer is actually another piece of casting software ...

It is Songcast from ... https://www.linn.co.uk/software

It is this ... https://github.com/openhome/ohSongcast

I am not sure if the version that I am using is the same as the version on Github.

[FA-Bubba]

@SamDel : Regarding "check the 'Automatically start devices at startup' option"...

Since my TV, which has a Chromecast dongle, is listed as a device, I don't believe I'll be using the "Start Devices at Startup" option (UNLESS, there is a way to designate 'preferred devices" for AutoStart).

I personally don't see this as a high priority, and I believe getting the App to run reliably with minimal device drop-offs would be the best focus for now.

[SamDel]

I think the "Start last used devices or groups" option is more useful in most situations. Maybe I can add a "Keep trying to get this device in playing state" option. Now there is a retry here and there, but when the retry didn't work it stops trying.

I'll create a 2.0 release tomorrow (when there are no blocking issues), then we can start adding (and testing) new features.

@GrahamDLL : Nice that the application works with a virtual soundcard like that, never tried. I'll post a new version later, that waits till the soundcard is up and running.

[SamDel]

See the board on what's done in Setup 2.0.1.zip.

I wait for about a minute now if the (virtual) soundcard isn't up and running yet when the application starts.

[FA-Bubba]

I just installed v2.0.1...
The UI now only shows two Device Boxes across versus the three it used to be... Perhaps a little less convenient, but it may incent me to start testing the Speaker Groups I created...

[SamDel]

The window is resizable now! And the size is persisted.

[FA-Bubba]

The resizable window is NICE! Sorry I didn't try that first...

FYI, v2.0.1 crashed in less than 1 hour of play -- it seemed to be trying to restore dropped audio, but was making weird noises (like water flowing). Other Apps also became responsive. so I had to reboot my PC. No entries in the Event Viewer, though...

After the reboot, I started v2.0.1 again, and it has been running OK for the past 3+ hours... Using the Speaker Groups now & no issues.

[GrahamDLL]

2.0.1

Start automatically when Windows starts .... Waits for Songcast to start as expected ... I uninstalled Songcast and the app waited and waited and then "connected to" the built in speakers ... All aspects of "start when Windows starts" appeared to work correctly.

Start last used at startup works as expected ... the logs for this are 039 and 041

The combination of start automatically with Windows and restart last used is less successful ...

I used Firefox to play a radio station and the app to cast the stream ... I restarted Windows while Firefox was playing and the app was streaming ... Firefox automatically restarted and began again to play the radio station ... the app started with Windows but did not start streaming and after a little while it crashed ... The logs from moments before the crash are 038 and 040 ... the Event Viewer entries for the crash are in the zip as evtx and as xml files

crash.zip

[SamDel]

I added a fix for the recording devices in Setup 2.0.2.zip, and there's a link to the wiki page on the options tab now.

[GrahamDLL]

2.0.2

Automatic start with windows plus automatic restart of devices equals long period of inactivity at startup followed by popup message to say that app is unable to find recording device ... Logs 042 + 043

Stop and start the app and everything works as expected ... Log 044

log042-044.zip

[GrahamDLL]

The question mark in the Options Tab is easily overlooked ... It took me several moments to find it even though I knew that something was there.

[FA-Bubba]

v2.0.2
I installed it, and when I launched it, no Devices populated into the Device Window. I Closed teh App & retried 2x, with same result.

The Log contained only one line (copied to image).

[SamDel]

Some more fixes to the recording devices in Setup 2.0.3.zip, and I changed the link to the wiki.

I didn't change anything in the discovering of devices that I'm aware of. I hope it's better now.

[FA-Bubba]

A lot of drop-outs & reconnects. Log & screenshot attached below...

Log-2019-02-22-v2-0-3.zip

[SamDel]

Nice to see a long log like that. A quick scan:

• I see devices dropping offline every now and then, auto restart works ok.
• During daytime devices drop offline every now and then.
• Between 23:42 and 9AM only a couple of devices dropped offline at 3AM.

That makes me think there's something during daytime (other network traffic?) that causes the devices to drop offline. Do you have audio drop-outs when the speakers restart, or also when playing 'normally'? I'll have a look later if I can improve something there.

[FA-Bubba]

I don't believe there is a lot of network traffic here. There are 4 PCs that are always on, but other than the one PC that I use for the AudioStreamer, there aren't many processes that are running. Each PC does get it's periodic updates from the Web (whenever those are pushed-out), and each PC does a backup between midnight & 5 AM, HOWEVER, my NAS isn't set up yet, so those backups are local, and not via the network. So at any given time, 3 of 4 PCs are in a dormant state (not hibernating, but just idle). Which ever PC is "active", it mainly for eMail, Web browsing, writing Docs, etc, and usually for 1 to 3 hours at a time.

I have some SmartDevices (lighting, Security Cams, monitored power outlets, etc), but I don't believe they generate much network traffic (the Cams are hardwired to a DVR, and I don't believe generate network traffic (unless I load the Viewing App), which is infrequent.

I haven't correlated the drop-outs to any specific activities; for example, the speaker in the room where I am typing this dropped-out & restarted FIVE times while I typed these three paragraphs... I can also hear other speakers when they make the "connection bleep", and I hear those throughout the day, multiple times per hour.

---

Another weird thing happened: I closed the App last night, and rebooted my PC. I restarted the App this morning, and it opened in a "miniaturized" state -- as if the main window had been resized to the smallest possible size. Here's a screen shot with some notes:

[FA-Bubba]

v2.0.3 had a Hard Crash today. From the Event Viewer, it looks as if it may be directly related to a manual Router Reboot I did... I realize that the Audio Streamer needs a network connection to stream the audio, but maybe it could go into a "standby mode" if the network is unavailable? ...then resume once the network is back?

Once the network was back up and stable, I restarted DesktopAudioStreamer, and it started as expected. (Except, it was "Tiny" again -- it would be nice if it 'remembered' the last resizing size...). Here are the Event Logs:

v2-0-3_CrashEvent.zip

[SamDel]

You were right, it had to do with the router reboot. I added a fix for that and for the window size.
I also changed something for the restarting speakers, can you post the log again after a day or so?

Setup 2.0.4.zip

[SamDel]

Thanks for letting me know. The application uses CSCore for the audio capturing, it failed in this class. More details about the specific error.

In 2.0.18 I removed the popup for the recording device error. And the application plays silence on the background. To make sure there's always audio to capture and stream. I'm not sure if this should be an option.

The clicking should be gone now @dday4thedeceiver. There's a bigger delay with mp3 compared to wav. Before the device was in buffering state all the time for you, causing drop-outs (and a smaller delay). Is there anything in the event viewer about the application hang?

[dday4thedeceiver]

1-Still no audio with mp3
2-The clicking is still there but perhaps the pattern changed. Now it's three clicks followed by several seconds of silence then it repeats.
3- Even though the device plays in wave mode, I get connection errors in the log. This was irrelevant, I rebooted the device and they are gone, the results are identical.
4- BTW, how about a filter by IP text box for the log? With six devices on the network it's a bit of a mess when testing with one.

Log in mp3 mode:
Check For Silence: 2.0024543

Check For Silence: 3.0036803

Check For Silence: 4.0039072

new Mp3Stream

out [7:43:29 AM][192.168.1.34:8009] [Buffering]: {"requestId":36,"type":"GET_STATUS"}

[7:43:29 AM] [192.168.1.34:33679] Last received message: 1/1/0001 12:00:00 AM

Check For Silence: 2.9870057

Check For Silence: 4.0002368

new Mp3Stream

Check For Silence: Send Silence (0.0040002)

Check For Silence: 2.0031608

Check For Silence: 3.0163895

Check For Silence: 4.0166943

new Mp3Stream

Check For Silence: Send Silence (0.0020005)

Check For Silence: 2.0147489

Check For Silence: 3.0139755

Check For Silence: 4.0142018

new Mp3Stream

Check For Silence: Send Silence (0.0020009)

Check For Silence: 2.0004571

out [7:43:44 AM][192.168.1.34:8009] [Buffering]: {"requestId":37,"type":"GET_STATUS"}

Check For Silence: 3.001773

Log in wave mode

Check For Silence: 2.0144568

Check For Silence: 3.0147407

out [7:45:45 AM][192.168.1.34:8009] [Buffering]: {"requestId":46,"type":"GET_STATUS"}

in [7:45:45 AM] [192.168.1.34:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":5,"playbackRate":1,"playerState":"BUFFERING","currentTime":8.807482,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"media":{"contentId":"http://192.168.1.2:14128/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Sandpiper","images":[]},"duration":null,"tracks":[{"trackId":1,"type":"AUDIO"}],"breakClips":[],"breaks":[]},"currentItemId":5,"items":[{"itemId":5,"media":{"contentId":"http://192.168.1.2:14128/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Sandpiper","images":[]},"duration":null},"autoplay":true,"activeTrackIds":[],"orderId":0}],"repeatMode":"REPEAT_OFF"}],"requestId":46}

in [7:45:47 AM] [192.168.1.34:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":5,"playbackRate":1,"playerState":"PLAYING","currentTime":9.804929,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":5,"repeatMode":"REPEAT_OFF"}],"requestId":0}

[SamDel]

I also had the clicking now, never heard it before. For me it's fixed in 2.0.19 (and I changed a couple of other things).

A device always has port 8009, groups have higher port numbers. The connection error was from port 33679 (that's a group), not from the device that's playing. A group can have a connection error when it gets another leader. I can tell more about what's going on if you zip and post the complete log.

I always copy the log and paste it in Notepad++. In Notepad++ you can search & filter on every field so there's no need to add that functionality in the application.

[FA-Bubba]

I ran v2.0.12 for about 6 days. After a Friday reboot, it ran continuously for just over 2 days, but a LOT of drop-outs this morning (drop-reconect-repeat for over an hour). I closed the App via it SysTray menu, but it remained loaded in memory, still dropping & reconnecting speakers. Log attached.

Log-2019-03-18-v2-0-12-DropOuts.zip

Just loaded v2.0.19

[SamDel]

There are timeouts for a couple of minutes at 1:43 AM (backup?).

And at 7:56 AM all devices drop offline at the same time. At the same time there's no audio captured anymore (so I think you were playing from a network/internet source). For about ten minutes there's no response at all, then (8:06 AM) all devices start playing again.

It looks like the network/router was completely down for a while. After that the connections are poor. Audio is captured infrequently (the player probably also has a bad connection.)) and the devices are 'buffering' a lot of the time.

[FA-Bubba]

I'm not aware of any activity at 1:43 -- it is possible that Windows was running it update service...

The PC that the App is on runs a backup at 2:00 AM, but does not use LAN resources -- it is to a local Drive.

I heard all of the dropouts around 8:00 AM...
The source has always been iTunes running on the PC the DAS App is on...

The dropouts continued, even after I tried to close the App via the SysTray icon -- the Window closed, but the App remained running in memory, dropping & reconnecting the speakers, until I forced a reboot.

[SamDel]

After further analysis:

I can explain why the audio capturing stopped (for ~ 10 seconds) at 7:56. The application couldn't send the stream packet, which has a timeout of 10 seconds. This thread was blocking the audio capturing thread. I changed the code, in the next version these tasks don't block each other.

And I changed the timeout for getting the device information from 100 to 5 seconds. It can be that the application didn't close (immediately) because of that.

[GrahamDLL]

the Window closed, but the App remained running in memory, dropping & reconnecting the speakers, until I forced a reboot.

I have seen this also ... I suspect there is a problem in this area ... Using "Close" on the pop-up menu when the app is mnimised to the tray causes the the app to disappear from the tray ... but ... the app stays in memory ... and ... is now inaccessible and has to be closed from Task Manager.

[SamDel]

Same here, the application didn't close at least once.

In 2.0.20 2.0.21 I improved it, smaller timeout values, cancel running tasks, stop trying to reconnect, disposing objects, etc. Let me know if it happens again!

[GrahamDLL]

2.0.21

Works as expectted ... fully closes when selecting Close in tray icon menu.

A couple of trivial cosmetic things ... the executable is called Chromecast.blah.exe though that might be intentional

The Devices tab shows the groups and devices with the device (or group) name with a "start" button to the left ... Hovering the mouse over the name changes the background colour ... hovering over the "start" button changes the mouse pointer ... Do you want to make this consistent by, for example, changing the background and the pointer when hovering over either of them? Currently, it looks as if clicking one does something different to clicking on the other.

[SamDel]

You're right about the device control, thanks. I'll change it in the next version.

I have created a new issue for the names!

[FA-Bubba]

Ran v2.0.19 successfully for several days without any issues.

Did my weekly reboot on Saturday AM, and restarted. Ran all day until around 6PM, then a LOT of drop-outs, and disconnects. The App tries to reconnect, but failed on just about every attempt.

I shut the App down, but it remained in memory. While I was in the TaskManager, I noted numerous (>20) instances of the Chrome Browser, which IO had run about an hour or 2 earlier, and closed (it looks like it remained in memory).

I manually unloaded it & the Desktop Streamer, and tried to restart the Desktop Audio Streamer, but it would not connect to any speakers (2nd log file - "Retry"). Had to dump it out of memory again & reboot. If I had to guess, I think that the Chrome Browser may have been a factor...

Log-2019-03-22v2-0-19-DropOuts.zip

[SamDel]

Today the application remained in memory for me too, after network problems. It had to do with filling the dropdown with IP addresses. Fixed it in 2.0.22.

If you like you can find out why it's hanging by:

• Right clicking 'ChromeCast.Desktop.AudioStreamer.exe' in the task manager, choose 'Create dump file'
• Start the DebugDiag 2 Analysis tool
• Click 'Add data files' to add the .dmp dump file
• Check 'CrashHangAnalysis'
• Click 'Start Analysis', and drop the .mht report here

[FA-Bubba]

Even after a reboot, I was still getting frequent drop-outs on v2.0.19, then I noticed something SNEAKY that Chrome had done: Chrome was auto-loading in the background, and staying in memory. I found the Chrome setting, and disabled that "Feature", and rebooted, confirming that it was no longer loading in memory.

This seems to imply that the Chrome Browser interferes with the Desktop.Audio.Streamer (or vice-versa).

Then I downloaded and ran v2.0.22...

AVG has resumed flagging something in the App (see pix below). I ran it anyway, and a few minutes later AVG popped-up and said it was OK.

[FA-Bubba]

I will post any findings on v2.0.22 when I have something relevant.

[GrahamDLL]

2.0.22

Used yesterday and worked as normal ... Was minimised to tray and not streaming overnight ... Attempted to start streaming this morning and would not start ... log057 is below ... Stopped and restarted the app and streaming began as expected.

log057.txt

[GrahamDLL]

2.0.22

Used yesterday and worked as normal ... Was minimised to tray and not streaming overnight ... Attempted to start streaming this morning and would not start ... log057 is below ... Stopped and restarted the app and streaming began as expected.

Ditto ...

log058.zip

[SamDel]

Nice bug! Is your desktop going into sleep mode overnight? The device connection is disposed when the desktop is in sleep mode, and not recovered again.

Fixed it in 2.0.23.

[FA-Bubba]

I switched to v2.0.23 this morning (no issues with 2.0.22).

For the first time, I tried the Lag control, with the intent to "sync" the sound from different speakers -- at certain volume levels, audio from multiple speakers can be heard, and it is almost always out of sync.

In short, I could not find a Lag setting that synced the audio... At minimum lag, speakers were constantly dropping and coming back on line, but the audio was not in sync. At maximum lag, drop-outs were minimal to none, and audio was still out of sync.

I'm guessing that this control is not intended to synchronize audio to all speakers concurrently...

To make an analogy, with an 'old-school' wired high-fidelity system, ALL speakers are always in sync, that is, a note sounds concurrently on all speakers. Is this something the Desktop Audio Streamer can do? Is it feasible for a future enhancement?

Thanks!

[SamDel]

The only way to get the speakers in sync is by using groups. The devices have a builtin mechanism to play groups synchronized.

The application is too 'loosily coupled' to the devices to get them in sync, where the old-skool setup had a direct wire to the speakers to send the audio signal.

The only use of the lag control is (I think) when you play a video on the desktop, and the audio on the devices. If you select wav as stream format you can get the audio and video more in sync with the lag control. It's done by only sending a percentage of the audio to the device (creating drop-outs). Then the buffer on the device is minimal and the device plays the audio it receives 'right away'.

I think of removing the lag control, or 'hiding' it in the config file. It's not of much use.

Nice that you had no issues with 2.0.22. I'll make a 2.1 release next week (if @GrahamDLL's issue is solved)

[GrahamDLL]

2.0.23

All good here ... Good recovery from sleep. Thanks.

My vote is to remove the lag control ... Does it add complication to fix something that nobody is saying is broken?

log059.zip

[FA-Bubba]

RE: Sync.... I'm testing using the groups instead of individual start-ups. The first thing I noticed is that individual volume controls no longer work -- all speakers in the Group react to a volume change. It would be preferable if changing volume via the Group Device changed all speakers in that Group, and changing the volume via the individual Device only adjusted that one speaker...

So far, all speakers in a Group seem to be synced very well. Speaker Groups are not synced with each other, though... This may not be an issue, because there are few places where I can hear speakers from different Groups at the same time.

Stay tuned for any additional observations.

[GrahamDLL]

So far, all speakers in a Group seem to be synced very well. Speaker Groups are not synced with each other, though... This may not be an issue, because there are few places where I can hear speakers from different Groups at the same time.

For the avoidance of doubt ... a speaker can be in more than one group ... I have a group for all speakers and a second group just for the downstairs speakers, The kitchen speaker is in both groups.

[FA-Bubba]

I have an "All Speakers" Group as well... I'm just not using it because it includes a TV that has a Chromecast, and I don't want to turn the TV on every time I listen to music.

[SamDel]

It would be preferable if changing volume via the Group Device changed all speakers in that Group, and changing the volume via the individual Device only adjusted that one speaker...

For me it works that way! The application only changes the volume on the selected device or group. The devices take care of updating the group's volume (average of devices) and the volume of the devices them selves (to reflect the changed volume).

The only change in Setup 2.0.24.zip is that the lag control can only be enabled in the config file, the checkbox is removed from the options tab. (and the french translations are updated)

[FA-Bubba]

I seem to have a slightly different experience with the volume controls:

Right now, I am playing to the "ALL Speakers" Group, and when I slide the Volume control on the ALL Speakers Device Box, volumes on all speakers change (which is what I would expect).

When I drag the volume slider for just the "Office Speaker", the volume of that speaker is changed, but the sliders on the "ALL Speakers" Device Box, and on the "Second Floor Speakers" Device box also slide in tandem with the movement of the Office Speakers slider. At first, I thought all of the speaker volumes were changing, but after making a significant change, then walking around to check, only the Office Speaker volume was actually changed...

The tandem movement of the Group sliders seems to be an anomaly, and the other speaker volumes are not actually changed.

Not a big deal, but visually, it fooled me.

v2.0.23 has been running continuously for 3 days without any issues.

[SamDel]

"Office Speaker" is a member of "All" & "Second Floor". When you change the volume of "Office Speaker", the average of the volumes of all devices in those two groups changes. That's why you see the sliders moving.

The group's volume is set to the average of all devices in a group. The devices take care of it themselves.
Also when you change the volume of a group, then the volume of all devices in a group change to reflect the new average.

I agree that it can look odd when you see the sliders moving 😉.

[SamDel]

I have created the 2.1 release, let's continue in Development 2.1