Development 2.0 about chromecast-desktop-audio-streamer

[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

[GrahamDLL]

2.0.4

All good.

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 ... Desktop Streamer began to stream the audio as it should. Logs 045 and 046.

The resize of the window works here as expected and the new size is retained when the app is stopped and started.

log045&046.zip

[SamDel]

Thanks, nice :)! For me it also works fine with 'Start when Windows starts' & 'Auto restart' checked. The application also 'waits' till the network card (IP adresses) is up and running now.

I had the 'tiniest possible window' issue today with 2.0.4. I'm not sure what causes it (yet).

[FA-Bubba]

v2.0.4 has been running continuously for 3 days; I was out of the house for much of this time, so I wasn't able to notice the frequency of drop-outs. For the times when I was working at my PC, I did notice a lot of brief drop-outs, some as short as 1 or 2 seconds... (Log is attached)

A sidebar on some of my speakers: I have some QFX E-350 speakers** attached via Chromecast Audio. I originally purchased these because they were promoted as WiFi Speakers; however, it was only after I received them that I discovered they were intended to ONLY run with the QFX Audio App, which meant I had to devote an iPhone or iPad to stream WiFi music... I eventually got them to play via iTunes on my PC by using AirPlay, but the WiFi stream was not particularly reliable.

Each of those speakers also has an Aux Input, so I am using them with Chromecast Audio, and they have been working great with your App. ONE ISSUE, not related to your App, though, is that when the Audio Stream stops for more than a 'few minutes', the speaker reverts to it's default WiFi Input setting, and the Aux In connection must be manually reset at each speaker, which is a bit inconvenient. I've browsed some forums looking for any hacks that would make the Aux In the default, but so far no luck...

I mention all of this just in case you may have a suggestion on how to hack the speaker so it defaults to Aux In instead of WiFi Audio... They would be GREAT speakers if I could make this one change.

** There are a LOT of results if you Google the speaker name, and here is the set-up guide:
http://www.qfxusa.com/Pdf/E-350Quicksetup.pdf

Note that the Amazon page has poor reviews (including one from me)...

Log-2019-02-27-v2-0-4.zip

[SamDel]

Only a couple of speakers dropped off-line during these three days.

• 'Office speaker' dropped off-line after 36 hours playing right after you decreased the volume. Before that it didn't respond to status messages for 90 minutes (I think playing continued these 90 minutes).
• 'Kitchen hub' restarted after 41 hours (I'm not sure why). Before that there were no status messages for 7 hours, I think it was still playing.
• 'Playroom speaker' & 'Guestroom speaker' also dropped off-line once and restarted after playing for a long time.

I also see 'buffering' messages every now and then, then you probably hear the audio drop-outs. Some periods all devices start sending buffering messages (a lot of network traffic?). Sometimes there are no 'buffering' messages for hours. I'm going to try to increase the buffer on the devices later.

I don't see an option to make aux-in the default source. I'll have another look later.
Some small fixes in Setup 2.0.5.zip for keeping the windows size, detect devices that go offline faster, etc.

[GrahamDLL]

2.0.5

Running all day without incident.

log047.zip

[SamDel]

Same here, the latest changes are doing fine. I see buffering messages in the log between 1:45 PM and 6:15 PM every couple of minutes. That's an indication that the buffers on the device are low, but maybe not enough to hear drop-outs.

In 2.0.6 I added a volume meter, for me it's more an indicator that there's capturing & streaming going on.
I also added a tooltip text to the group icon, is it good enough to distinguish from devices?

And I added a dropdown to set the buffer on the device.
If you set it to 15 seconds an initial buffer of 15 seconds is send to the device (the buffer size can change over time of course). It means the lag between the desktop and the device also increases with 15 seconds. The lag between devices shouldn't change. If you have a lot of drop-outs you can try to increase the buffer size.

[FA-Bubba]

I've been running v2.0,5 for about 3 days now. A number of disconnects, some for extended periods of time. I rebooted the PC on Sat AM, and resumed playing through Sunday night. Still some drop-outs... Here are 3 Logs:

Log-2019-03-03-v2-0-5.zip

[SamDel]

There are quite a lot of network timeouts in the logs. I changed the socket timeout to 1 second in 2.0.5 (to detect disconnects faster), I think that's the cause of a lot of the disconnects.

In 2.0.7 the socket timeout is 10 seconds.

[FA-Bubba]

I just loaded v2.0.7...
Will try different buffer settings if/when I experience dropouts.

[GrahamDLL]

2.0.7

All good.

log048.zip

Before the above ... I left Streamer minimised to the tray and unused for a couple of days. During that time, my network mucked up and a couple of Chromecast devices disconnected. When I came back to Streamer it was unresponsive and had to be closed from Task Manager. I noticed that Streamer was using about 260 Meg of memory. The log tab had been open and I guess it was the log that consumed the memory and caused Streamer to lockup. You might want to stop writing to the log when it gets to 20 Meg or whatever.

[dday4thedeceiver]

Throwing these in here as they are really minor:
1- Recording device is not saved and resets at startup
2- Using a third-party app for this, but minimize to tray option would be nice.

BTW 2.0.7 works great so far. FWIW, I'm using it with a virtual audio device (Virtual Audio Cable) and I set the programs I want to cast from to output to Virtual Audio Cable, mainly VLC receiving notifications from Smartthings. Also, 'accidental' use case: it's great for quickly fixing volume levels on all devices!

[FA-Bubba]

Interesting Event:
While running v2.0.7, and streaming audio from my PC, my daughter asked Google to play a song ("Hey, Google, play <title by artist>")... Google responded, and started playing the song, but after a few seconds it abruptly stopped, and the Desktop Audio Stream resumed. We tried this 3 times with the same results...

I am guessing that when that Google device started playing music from its (external) source, the Desktop Audio Streamer detected that as a 'drop-out', and reconnected the speaker to its stream...

I'm also guessing that if we had first said: "Hey Google, Stop the Desktop Stream", it MIGHT have worked differently (see attached photo below), but I'm not aware if Google has that capability... I'm pretty sure if I had disconnected that Google speaker via the Device Window, the Google-sourced music would have played OK

Not a big deal, but I am wondering if the App can be integrated with Google Home/Google Assistant, so a verbal command like "Hey Google, Disconnect the OFFICE SPEAKER from the Desktop Stream", would remove that speaker from the Audio Stream. Similarly, a verbal command like "Hey Google, Connect the OFFICE SPEAKER to the Desktop Stream", could be used to (re)connect that speaker.... (Food for thought?) For what it's worth, I think that would be a great feature!

FYI, this is what the Google Home Hub displays when the Desktop Audio Streamer is running:

[dday4thedeceiver]

That is true, auto-reconnect cuts in even if the device is busy - this will be a problem. Check for idle status before reconnecting?

[SamDel]

Changes in Setup 2.0.9.zip:

• @GrahamDLL - I also noticed performance problems when there is a lot of log in the text-box. Now I clear the contents of the text-box automatically if the content > 2Mb. But I keep the log in memory until it's > 100Mb. So when you do 'copy to clipboard' you can get up to 100Mb. I didn't test it for multiple days so let me know!
• Thanks @dday4thedeceiver - You can minimize to tray by clicking the tray icon (show/hide window). You can also uncheck the 'Show window at startup' option. In 2.0.9 the recording device is also saved.
• In 2.0.9 I'm checking the status before auto-reconnecting. The application is only reconnecting when the status is empty or 'Desktop Audio Streamer'. (The status text is also shown at the bottom of a device box.) In theory that should work, let me know if there are any side effects!

Nice @FA-Bubba ! Is it a recent picture? I thought I changed it to 'Desktop Audio Streamer'. I think it's also possible to send a picture to the Hub, is there any use for that? I hope 2.0.9 fixes it for your daughter 😉.

I don't have a Google Home device so I don't know much about the commands, is there a good manual somewhere? When another application starts streaming to a device the application receives a 'close' message from the device. I'm not sure but I think the application also gets a 'close' message after a "Hey Google, Stop the Desktop Stream" command. Before, with auto-reconnect checked, the application was always reconnecting. In 2.0.9, when Google plays a song, the status should change and the Desktop Audio Streamer does not reconnect. I didn't do much testing on it yet..

[SamDel]

There was a bug in the recording device drop down, please skip 2.0.9 and use 2.0.10.

[FA-Bubba]

I just loaded v2.0.10...
I was running v2.0.7 for several days, with no significant issues (only the event I mentioned earlier today when the App restarted while Google was playing a requested song).
Here's the log:

Log-2019-03-08-v2-0-7.zip

[SamDel]

• First thing I notice in the log is the (reduced) number of 'buffering' messages being sent by the devices. In the 2.0.5 log there were 762, in the 2.0.7 log 113. Did you use the new device buffer option? How many seconds? Less drop-outs?
• The number of disconnections are about the same.

I was looking for the 'Interesting Event' in the logs but I didn't find it.

[GrahamDLL]

2.0.10

It appears that there may still be a problem with recording device selection ... When I select another device in the dropdown it reverts to the previous device.

[FA-Bubba]

The 'Interesting Event' was when Google was asked to play a song while the Desktop Audio Streamer (DAS) was running. Google responded & started to play that song, but it seems that the DAS considered that a drop-out, and over-rode Google, resuming the Audio Stream. This was on the Kitchen Hub, but I don't recall the Date/Time. I will test that sequence later today with v2.0.10

So far, I have not adjusted the Device Buffer Option. I was away much of the time that is covered by the 2.0.7 Log I sent, so I don't have a viewpoint of the frequency of drop-outs.

And, the previous display picture I sent was from Feb 20... Here's the current screen:

[SamDel]

Now I see the 'Interesting Event' in the log. The status changes to "YouTube Music", and the application receives a 'close' message. The fix should work then.

[FA-Bubba]

I've been running v2.0.10 for about 24 hours; two logs attached -- the first one with "Disconnects" that were caused by my router going off line. I believe the second Log is fairly clean -- the PC the App is on does an auto-reboot every Saturday morning, so it may only have entries from around 5 AM this morning.

I tested the Google Music 'event' earlier today, and it worked as you expected: I asked Google to play some music from an external source; it played for a while until I told Google to "Stop the Music". The Hub went back to its "Ambient State" (idle state), and after about 5 to 10 seconds, the Audio Stream restarted.

I think it works GREAT!.... I can now ask Google to do something, and the streamed music will resume once Google's task is completed.

Thank you for the great work!

Log-2019-03-09-v2-0-10.zip

[dday4thedeceiver]

Ehh... my Google Homes still report playing music even after I stop them, both in the log and in the Home app.. I have two different kinds too (one Insignia, one Mini) and they both do the same thing. Ugh. So I'm guessing the Hub behaves properly, the speakers do not :( I go into the home app and stop the (already stopped) cast and then DAS reconnects beautifully, but until then it won't.

How about a "Force reconnect after X minutes" option?

UPDATE: After mucho googling, "Stop speaker_name" works. However nobody in the household will remember to do that, so the force reconnect would still be nice.

[FA-Bubba]

FWIW, I have a Google Home Hub, 3 Google Minis (soon to be 4), 2 Chromecast Audios & 1 Chromecast Video setup in the Desktop Audio Streamer App, and I haven't encountered the issue @dday4thedeceiver has described. I do get a lot of buffering drop-outs that auto-recover (and I haven't yet experimented with the Device Buffer option).

I can ask Google to play music from its external sources, and the device drops off of the App, displaying "Connected Google Play Music"... Then, after saying "Hey Google, Stop Google Play Music", the Audio Stream resumes.

Check out the end of this log -- there may be some info near the end on the drop-outs:

Uploading Log-2019-03-10-v2-0-10.zip…

[FA-Bubba]

The log failed to upload, so here it is:

Log-2019-03-10-v2-0-10.zip

[FA-Bubba]

The log failed to upload, so here it is:

Log-2019-03-10-v2-0-10.zip

[FA-Bubba]

UPDATE:
I rebooted my PC, and restarted the App. It floundered-around, connecting then immediately dropping every speaker, for about 20 minutes, then finally connected and played audio. Here's the log:

Log-2019-03-10-v2-0-10-NotConnecting.zip

[dday4thedeceiver]

Odd... My Cast firmware version on the minis is: 1.37.146679 - does it match yours?

[FA-Bubba]

@dday4thedeceiver, the Cast Firmware on my minis is: 1.36.141215

[FA-Bubba]

@dday4thedeceiver, the Cast Firmware on my devices are:
Mini: 1.36.141215
Mini: 1.37.146679
Mini: 1.36.141215
Chromecast TV: 1.37.148642
Chromecast Audio: 1.37.146679
Chromecast Audio: 1.36.141215
Google Home Hub: 1.37.146679

I'm not sure how (or if) Google pushes out updates -- I haven't seen any options for auto-updating.

[SamDel]

Nice that the fix works! I can reproduce the behaviour of both scenario's with Spotify:

• If I STOP casting Spotify then Desktop Audio Streamer resumes.
• If I PAUSE Spotify then the status stays 'Spotify' and Desktop Audio Streamer doesn't resume. So I think @dday4thedeceiver's command is interpreted as PAUSE, instead of STOP. I don't know why.

@FA-Bubba logs:
At the end of 'Log-2019-03-10-v2-0-10.zip' there are drop-outs. I can't tell if something goes wrong on the application/desktop side (audio capturing) or if something's wrong on the network side.

In 'Log-2019-03-10-v2-0-10-NotConnecting.zip' the devices are opening a stream connection but they don't receive any audio packets for ~15 minutes.

All together it can be that the sound card (driver) is not 100% functioning all of the time. I need to add some extra logging to be sure what goes wrong there. I'll drop a new version later.

[dday4thedeceiver]

BTW, I have been running into consistent audio dropouts (which one initially suspects is a buffering problem) that have nothing to do with DAS - the Virtual Audio Cable device I'm using was causing the problem somehow, and I can't fix it or find another free virtual audio device driver.

So if anyone needs to cast anything other than the primary sound output, using a secondary hardware audio device is the way to go instead of trying to get VAC to work without dropouts.

[SamDel]

Thanks, I've added a line in the troubleshooting section in the wiki about it.

@GrahamDLL is also using a virtual device, here's his comment about it. You don't have drop-outs, do you @GrahamDLL?

[SamDel]

In 2.0.11:

• a fix for the recording device selection issue
• extra logging for the audio recorder. I hope something is logged now ...

[SamDel]

In 2.0.11 the application didn't close (for me) Fixed it in Setup 2.0.12.zip.

[dday4thedeceiver]

UPDATE: TL;DR - The dropouts were a network issue. Even though in practice I have zero issues with my 5ghz network, it was resulting in a (usually) single dropout at the beginning of the stream. 2.4ghz Wifi worked a lot better, and wired fixed it. VAC has nothing to do with it, sorry.

Here's the log filtered to just one speaker (would be a nice option btw) on 5ghz wireless. I noticed the state goes to "buffering" when the dropout occurs and goes back to playing when the audio resumes, but the funny thing is it continously does that even when idle - is that normal?

in [9:00:29 AM] [192.168.1.132:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":144.03486,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

in [9:00:32 AM] [192.168.1.132:8009] [Playing]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":145.418073,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

in [9:00:33 AM] [192.168.1.132:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":146.421982,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

in [9:00:35 AM] [192.168.1.132:8009] [Playing]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":147.482857,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

out [9:00:37 AM][192.168.1.132:8009] [Buffering]: {"requestId":186,"type":"GET_STATUS"}

in [9:00:37 AM] [192.168.1.132:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":147.482857,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"media":{"contentId":"http://192.168.1.2:2983/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Desktop Audio Streamer","images":[]},"duration":null,"tracks":[{"trackId":1,"type":"AUDIO"}],"breakClips":[],"breaks":[]},"currentItemId":1,"items":[{"itemId":1,"media":{"contentId":"http://192.168.1.2:2983/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Desktop Audio Streamer","images":[]},"duration":null},"autoplay":true,"activeTrackIds":[],"orderId":0}],"repeatMode":"REPEAT_OFF"}],"requestId":186}

out [9:00:37 AM][192.168.1.132:42542] [Connected]: {"requestId":181,"type":"GET_STATUS"}

in [9:00:37 AM] [192.168.1.132:42542] [Connected]: {"requestId":181,"status":{"userEq":{"high_shelf":{"frequency":4500.0,"gain_db":0.0,"quality":0.707},"low_shelf":{"frequency":150.0,"gain_db":0.0,"quality":0.707},"max_peaking_eqs":0,"peaking_eqs":[]},"volume":{"controlType":"master","level":0.6749999523162842,"muted":false,"stepInterval":0.05000000074505806}},"type":"RECEIVER_STATUS"}

in [9:00:50 AM] [192.168.1.132:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"PLAYING","currentTime":149.02217,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

out [9:00:52 AM][192.168.1.132:8009] [Playing]: {"requestId":187,"type":"GET_STATUS"}

in [9:00:52 AM] [192.168.1.132:8009] [Playing]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":149.520408,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"media":{"contentId":"http://192.168.1.2:2983/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Desktop Audio Streamer","images":[]},"duration":null,"tracks":[{"trackId":1,"type":"AUDIO"}],"breakClips":[],"breaks":[]},"currentItemId":1,"items":[{"itemId":1,"media":{"contentId":"http://192.168.1.2:2983/","contentType":"audio/wav","streamType":"BUFFERED","metadata":{"type":0,"metadataType":0,"title":"Desktop Audio Streamer","images":[]},"duration":null},"autoplay":true,"activeTrackIds":[],"orderId":0}],"repeatMode":"REPEAT_OFF"}],"requestId":187}

out [9:00:52 AM][192.168.1.132:42542] [Connected]: {"requestId":182,"type":"GET_STATUS"}

in [9:00:52 AM] [192.168.1.132:42542] [Connected]: {"requestId":182,"status":{"userEq":{"high_shelf":{"frequency":4500.0,"gain_db":0.0,"quality":0.707},"low_shelf":{"frequency":150.0,"gain_db":0.0,"quality":0.707},"max_peaking_eqs":0,"peaking_eqs":[]},"volume":{"controlType":"master","level":0.6749999523162842,"muted":false,"stepInterval":0.05000000074505806}},"type":"RECEIVER_STATUS"}

in [9:00:53 AM] [192.168.1.132:8009] [Buffering]: {"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":149.520408,"supportedMediaCommands":274447,"volume":{"level":1,"muted":false},"activeTrackIds":[],"currentItemId":1,"repeatMode":"REPEAT_OFF"}],"requestId":0}

By the last entry at 9:00:53 it's already done.

[GrahamDLL]

2.0.10

Streaming for 48 hours (or perhaps 72 hours) caused a 85 Meg log to be created and DAS didn't hang

log051.zip

[GrahamDLL]

2.0.12
2.0.12

It still won't change the source device ... I click on the "other" device in the dropdown list and it promptly reverts to the "original" device.

For future reference ... The arrival of Sandpiper resulted in two entries in "Run" in the registry so DAS started twice ... I have edited the registry to fix it.

The .EXE file is still called Chromecast ...

Capture.zip

[SamDel]

@dday4thedeceiver : I removed the VAC line from the wiki. The dropout in the beginning of the stream can also be caused by the application. I keep a buffer of recorded data to start streams faster, I'll have a look at that code.

Ideally you only have one 'in' message with "playerState":"BUFFERING" when you start the stream.
And after that only "playerState":"PLAYING" messages until you stop the stream. The device only sends buffering messages when it's buffer is empty (I assume). In theory audio capturing as well as network issues can cause an empty buffer on the device. You can try try changing the 'Device buffer' to get a bigger initial buffer on the device.

@GrahamDLL :

• Now I know why I had two instances running after booting 😉. I'll keep the registry entry on 'Desktop Audio Streamer' for now. I was playing with a name, not sure about it yet.
• There's an error when you select the recording device (Initialize caused an error: 0x8889000f, "Unknown HRESULT".). I don't know what's wrong with it. When a recording device cannot be initialized the application switches to a device that can be initialized. I'll add an error message there, then you know what's happening.
• Very little problems in your log, some buffering messages. On the background the application keeps polling a port that's no longer in use (after (un)plugging a network cable?). Maybe I can change something there.

[GrahamDLL]

Personally, I like Sandpiper ... but I suspect that people will abbreviate anything more than two syllables and will be referred to as SP 😉

Piper might work without the sand ... or Curlew.

[FA-Bubba]

I noticed the App name changed (again)... It is now displaying "Sandpiper" on the Google Home screen (see image below). Will this be the App name going forward? Just curious, what is the logic behind this name choice?

[dday4thedeceiver]

I have played with buffering - settings don't make a difference, beyond delaying the audio start. I'm going to test longer with wired networking to make sure it really nukes the problem.

Probably unrelated: my devices always say Buffering (and sometimes Playing) while idle as long as DAS is connected to them. Is this normal behavior? Or is it because most of my stop cast commands only pause the cast?

In other words, when a device is connected but not playing anything, I still see a cast in the Google Home app.

[SamDel]

@FA-Bubba : The bird on my avatar is a sandpiper, that's where the name came from. I was thinking Winstreme, streaming, piping, sandpiper (, soundpiper). I don't think it will be the name, it's just to start the discussion.

@dday4thedeceiver : Good that you mention it. Your desktop is playing only small samples, isn't it? When there's nothing playing, no audio is captured and streamed (the application sends small silence-packets then to keep the streaming connection alive). Then the status is 'buffering' most of the time.

I did a test with playing small samples, and also had dropouts. It has to do with the mp3 encoding, with 'Wav' selected as stream format I didn't have dropouts. And you? I'll see if I can improve it.

[FA-Bubba]

@SamDel OK, good idea... I'll give it some thought and try to come up with appropriate naming ideas.

Here's another topic for a future enhancement: Why not incorporate the audio technology that can identify the song that is playing, and display it on the Home Screen? Several Apps do this now: Shazam, SoundHound, and Google Sound Search (https://assistant.google.com/services/a/uid/00000024216d4bb8?hl=en-US ), to name a few. Then there's databases like 'Musipedia' (https://www.musipedia.org/ ), as well as Audio Fingerprinting (https://www.acrcloud.com/identify-songs-music-recognition-online/ ) ... Perhaps one of these services could be integrated with DesktopAudioStreamer to provide a similar result... (Food for thought)

Interestingly, when I now ask Google: "Hey, Google, What song is playing?" Google responds: "You're listening to 'Sandpiper'."... However, when Google is playing from an external source ("Hey, Google, Play sum Jazz.") , the same question results in Google properly identifying and saying the current song and artist...

So at this point, it seems that Google is not aware of the audio content in the DesktopAudioStream ('Sandpiper')... MAYBE, if any of the above references can be integrated, the App could update the screen with the song title (and maybe the artist as well), so it would be displayed along with the App name, For example, the screen would display something like: (" 'Time After Time' by 'Miles Davis' on 'Sandpiper'." -- see image below), AND you could ask Google 'What's playing?', and it would respond audibly with: "You're listening to 'Time After Time' by 'Miles Davis' on 'Sandpiper'."

[dday4thedeceiver]

I think you nailed it. Wave output is much better, although not 100% reliable because (especially since I'm casting to multiple devices) I think it saturates the bandwidth at times - however the output is different further indicating it's a separate issue than mp3 cutout: With wave, the rest of the audio is gone when it drops, with mp3 there is a pause of several seconds and then the audio continues.

Wave isn't too bad, I have taken out a couple of unnecessary speakers and seems to be working fine for now. I'll let you know how it goes in practice.

---

On the id issue, the song name could be retrieved by this without trying to ID the song: https://www.last.fm/api/show/user.getRecentTracks - however I looked around a bit and unfortunately all the various last.fm scrobblers, official and non-official seem to be either dead or on their way out. On the recognition front, Cortana song ID service is also discontinued and Shazam isn't supporting PC anymore, arccloud & audd are payola...

[SamDel]

Nice feature @FA-Bubba ! I created a new issue for it.

In 2.0.14:

• @GrahamDLL : I added a popup when selecting a recording device that can't be initialized.
• @dday4thedeceiver : Improved audio quality when playing small samples and streaming in mp3 format (it's not perfect yet)

[dday4thedeceiver]

.14 doesn't work for me at all. With mp3 I get "New MP3 stream" in the log, and nothing else. With wave, I only see "bufffering" on the device but no "playing". Either way nothing plays.

[SamDel]

@dday4thedeceiver : can you try Setup 2.0.17.zip?

[dday4thedeceiver]

Wave works now, mp3 is still the same (nothing in the log) UPDATE: Got output from mp3 but after a huge delay, sound repeating and repetitive clicking during silence. Experimenting... I can't get output from MP3 again... the clicking issue seems separate, I get clicking at half a second intervals during silence without playing anything in wave mode but not mp3, so reverting back to .12 Also the process doesn't quit and has to be killed in task manager, which is not a big deal but it launches multiple instances in parallel.. you may wanna check for an existing process on startup. And the installer installs to ..\Desktop Audio Streamer\Desktop Audio Streamer as opposed to just ..\Desktop Audio Streamer

[GrahamDLL]

2.0.12

Uninstalled Songcast virtual speaker ... rebooted ... started music playing to laptop speakers ... attempted to stream using DAS and nothing happened.

log054.zip

[SamDel]

The same error as before: The recording device that's left can't be initialized:
IAudioClient::Initialize caused an error: 0x8889000f, "Unknown HRESULT".
In 2.0.14 I added a popup when a device can't be initialized.

I can't tell what's wrong with the laptop speakers. Can you record audio with other applications?

[GrahamDLL]

In 2.0.14 I added a popup when a device can't be initialized.

I can't tell what's wrong with the laptop speakers. Can you record audio with other applications?

The popup pops up repeatedly ... There can be 50 pop-up dialog boxes on screen if I don't get to it in time.

I cannot see that there is anything wrong with the built-in speakers. They play music okay and I can't see any errors in the Event Viewer.

The latest version of DAS pops-up an error message when it starts even though the built-in speaker is not selected in options.

I strongly suspect that I tried swapping audio devices about a month ago and it was working then.

[SamDel]

You can test with an older version, 1.9.51 worked for you in february. I'll remove the popup.

[GrahamDLL]

1.9.51

has the same problem.

If it is only me ... you can forget it because I don't capture audio from that device.

[SamDel]

If 1.9.51 worked in february, and not anymore then something must have been changed on your desktop.
Maybe the virtual device changed something?

[GrahamDLL]

If 1.9.51 worked in february, and not anymore then something must have been changed on your desktop.
Maybe the virtual device changed something?

2.0.17

I uninstalled the laptop speakers in Device Manager ... rebooted ... Windows reinstalled the device ... and DAS was then happy with the device. I have no idea what I did that broke the internal speaker setup but it's all fixed now. This is not, and never was, a problem, with DAS.

Thank you for your help.

[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