Edcast Asio randomly stops streaming, still thinks it's connected

[GoogleCodeExporter]

Using the latest version of Edcast Asio (3.37.2011.1214,) on both Windows XP 
(32-bit) and Windows 7 (64-bit) using both real and virtual ASIO drivers, 
Edcast Asio stops streaming, but still thinks it's connected to the Icecast 
server. This can happen anywhere from 10 minutes to 14 days after streaming 
starts, with everything in between. It seems to occur more often with higher 
network latency, I.E. when streaming to a remote server from Wi-Fi vs. 
ethernet, but this still happens even when client and server are on the same 
machine, where network latency isn't an issue. It may have something to do with 
CPU use, although I can't reproduce the issue on demand, even driving the CPU 
to 100% on purpose when streaming. Output format doesn't matter. I've tried 
ogg, mp3, ogg flac and AACPlus V2, on both local and remote servers, with 
several different hardware/software configurations, all with the same 
unpredictable drop. Also, the limiter is disabled, as I prefer to use my own 
custom processing. Nothing useful is written to the log, even in debug mode, 
when this happens. I have noticed that, occasionally, when streaming at 128 
KBPS AACPlus V2, the transfer rate, according to Edcast Asio, drops to 115 KBPS 
after it actually stops sending data.

I have tried Edcast Asio with the following drivers/interfaces:
Lexicon Alpha, Focusrite Saffire Pro14, Presonus StudioLive 16.4.2, M-Audio 
Delta Audiophile 24/96, ReaRoute (Reaper's virtual Asio driver,) and Asio4all 
v2, all with the same result.

Original issue reported on code.google.com by BorrisIn...@gmail.com on 7 Apr 2013 at 8:15

[GoogleCodeExporter]

 I am actually using an old version built in Nov 3, 2008. I can't find the exact build. I too am using a Lexicon alpha and have observed your issues so this may be a very old bug involving the driver, chipset, or how something is handled in regard. Disheartened to find this post virtually abandoned though as I was searching for answers. My OS is winXP 64 bit on the broadcasting PC. 

 The VU meters will just go dead randomly and of course the source right along with it. I cannot duplicate it. Very frustrating to have to constantly check on the encoder. I live mix and the streamer is a different PC with hardwired LAN. Constantly looking over my shoulder at a different screen while trying to mix is beyond frustrating. My server disconnects a dead stream after 10 seconds, but if I catch it in time I can select the desktops built in Realtek from the drop down, then move back to the alpha and it picks right back up upon re-tapping from it.

 The Alpha comes with a long USB cable, so I went down to a 6ft with a large choke wrap. The card is very stable using anything else. This does not appear to happen with built in sound cards for me either. Could this be a buffer issue for USB devices? A comm timeout due to too many USB devices on the bus? They're getting popular and cheap. Perhaps someone on the project team could lend us a hand on this? I'll upgrade but as per the post above, I don't expect much change. FWIW I don't use an ASIO driver and disabled all other USB audio devices (Ie. Webcams) in device manager. My only two options are built in and Alpha external.

 Thanks!

 - Matt

Original comment by mspy...@gmail.com on 27 Jul 2013 at 2:14

[GoogleCodeExporter]

I have long ago discovered that the interface used makes no difference. The 
Lexicon Alpha was just one of many test subjects, and, in this case, isn't 
necessarily relevant to the issue. I've used both virtual and hardware asio 
drivers, Firewire, USB and PCI included, on both 32 and 64-bit versions of 
Windows XP and Windows 7, including a 32-bit Windows XP virtual machine. I've 
also tried ReaRoute (Reaper's virtual asio driver) as well as asio4all. I've 
tried both 44,100 and 48,000 HZ with every codec Edcast supports. Nothing 
changed, and I have still not managed to make this happen on demand, even under 
high system stress.

I've had to halt a streaming project using a unique setup that requires 
streaming from a virtual asio driver (WDM isn't an option due to the routing 
matrix,) and I can't find another way to stream to Icecast from an asio driver 
in Windows, so I would love to see this fixed as well.

Original comment by BorrisIn...@gmail.com on 27 Jul 2013 at 3:23

[GoogleCodeExporter]

I believe this is happening when Edcast's network transmit buffer fills up.  If 
you simulate a slow network connection, you can reproduce this problem 100% of 
the time.

Original comment by izzy4...@gmail.com on 2 Jan 2014 at 12:02

[GoogleCodeExporter]

All development on edcast has ceased. Sorry

Original comment by jaroma...@gmail.com on 21 Dec 2014 at 11:27

• Changed state: WontFix
• Added labels: Type-Other
• Removed labels: Type-Defect