PDA

View Full Version : anyone look at SlimServer for media playback?



kurtlewis
July 24th, 2006, 09:23 PM
Open source, FREE and made to have plugins developed for it, might be a decent alternative to JRMC?
http://wiki.slimdevices.com/index.cgi?SlimServer
http://wiki.slimdevices.com/index.cgi?DeveloperGuide
http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap
http://wiki.slimdevices.com/index.cgi?SlimServerPlugins
I like JRMC's features, but if you are into good sound quality it is absolutely horrible. JRMC is also a complete CPU hog.

Developer-minded music lovers, please have a look- NR would seem to be a perfect front end for the slimserver backend. If anyone wants to start something I'd be happy to help test.

Ben S
July 27th, 2006, 08:47 PM
Interesting. How does this interact with their hardware?

kurtlewis
July 27th, 2006, 09:26 PM
Well, from what I know of it they use the server software for communicating with their various hardware devices- or, all of the user-submitted software client apps. It is not neccessary to own a hardware device to use it. I was reading a forum post and one enthusiast has the server software integrated with MainLobby on a tablet PC for the client app. (um, shouldn't he be using NR?? :))
From what I have read the media server is fully open-source and uses a TCP command interface (perfect!) - Even though I am very much a novice with programming of any sort this looks extremely promising, and it is supported by a group of open minded audiophile enthusiasts: http://www.slimdevices.com/dev_overview.html

Check out the user-submitted plugins, including dev tools here: http://wiki.slimdevices.com/index.cgi?SlimServerPlugins

Check out some of the client apps here:
http://wiki.slimdevices.com/index.cgi?PluginPlayers
Specifically this gui: http://softsqueeze.sourceforge.net/
Screenshots: http://softsqueeze.sourceforge.net/skins.html

If I have time this weekend I'm going to d/l and mess around with it.

kurtlewis
July 27th, 2006, 09:39 PM
This page might be of particular interest to you Ben-
http://www.slimdevices.com/dev_resources.html

My bad- they might be using a UDP protocol... but the new softsqueeze free client uses their new TCP protocol. So it's probably the latter..



Documentation
The developer documentation is included with the SlimServer software under Technical Information. There you'll find information on writing plugins, skins, APIs and specifications for Slim Devices' UDP communication protocol.

MeSue
July 27th, 2006, 11:32 PM
I have a Squeezebox so I run SlimServer here. I still prefer JRMC for things like smartlists, play counts, ratings, data collection. Unfortunately the two can't interact (yet?).

emmee
July 28th, 2006, 09:26 AM
I like JRMC's features, but if you are into good sound quality it is absolutely horrible. JRMC is also a complete CPU hog.


Hm, this is the first time I've heard these complaints.

It's also completely opposite my own experience with MC.

MC is bit-perfect with uncompressed or lossless formats. It uses what's supposed to be the best MP3 encoder / decoder. Just what is so 'horrible' about MC's sound quality and how have you come to this conclusion?

As for CPU load, even when playing compressed music, MC's CPU usage hovers around zero when I look at the process in Task Manager. How are you measuring CPU load and how high is it?

Have you posted your findings over on Interact to get some feedback from J River? Perhaps there's something wrong with your setup?

kurtlewis
July 29th, 2006, 02:55 PM
Hm, this is the first time I've heard these complaints.

It's also completely opposite my own experience with MC. Hi emmee-sounds like I may have offended with my comments, not my intention just my experience / opinion from using the software, which btw I still use. Please share your experience and I'm interested to know what comparisons and hardware you have used to validate your tests? What sound card, amp and processor are you running?


MC is bit-perfect with uncompressed or lossless formats. It uses what's supposed to be the best MP3 encoder / decoder. Just what is so 'horrible' about MC's sound quality and how have you come to this conclusion? I have a growing business building ultra high-end theater PC's for integration into medium to mega sound systems.
Now, I do believe that JRMC will sound totally fine to most folks with avg. receivers / speakers, and let me clarify- The sound quality is decent, but once you start running very revealing PC sound cards, processors and amps from Theta / Meridian / Arcam / Levinson with high quality cables and speakers, you do notice very large sound quality differences between the software players. MC's sound output lacks depth, presence and transparency.
On our test HTPC rigs, we are using a LynxTwo-B sound card on one and a LynxAES-16 on the other (these are the best sound cards you can get, the AES16 boasts 142db of headroom!)- We run either AES/EBU or SPDIF directly to the processors for non-audio playback, and are presently testing the LynxTwo-B's 2-channel and 6-channel analogue out sections for PCM (mp3's) and HDCD playback.
Other software players (supposedly bit-perfect as well) that I have tried which do not sound tops in our testing are itunes, WinDVD and Winamp.
Zoomplayer sounds pretty good due to ability to use a wide variety of plugins, and our top-honors goes to PowerDVD 6- Especially for CD playback. I honestly don't know why, but the sound quality from this software is extremely transparent and open.
Now, we also test these software players against traditional hardware. In our test cases we always eval sound quality for CD and DVD head-to-head with a Faroudja transport ($10k) and an Arcam transport ($5k). testing against hardware players which we know sound flawless always gives us a steady reference point for basing opinions.


As for CPU load, even when playing compressed music, MC's CPU usage hovers around zero when I look at the process in Task Manager. How are you measuring CPU load and how high is it?
What I have consistently seen (running v11.1) is up to 50% cpu during music playback and usually stays around 28-30%. Using taskmgr as well for checking.


Have you posted your findings over on Interact to get some feedback from J River? Perhaps there's something wrong with your setup?Have not posted, and I'm certain that there are no installation problems or problems with our test HTPC's.

So anyway, my goal here is to simply contribute some new ideas to the forum / community here, and I was thinking the SlimServer might be an interesting avenue to explore- I'm not looking to create a negative vibe towards JRMC, I still enjoy using it since there are no other solutions which offer as much integrated functionality with G4 / NR. I'm just looking for alternative solutions which may offer somthing similar and sound (IMO) a bit better

Ben S
July 30th, 2006, 09:26 PM
Hi Kurt -
I'm more interested from another standpoint. If someone can put a Slim device near their equipment and NetRemote can control it, that would be great. This would extend NetRemote's usefulness beyond those of us that have PC's hooked up to our whole-home audio systems.

MeSue
July 30th, 2006, 10:31 PM
SlimServer uses a Web UI (besides the remote control) for controlling the Squeezebox. There are several different "skin" styles including some for handhelds and touch-screens. There are also a couple of PPC-capable apps for controlling Squeezebox. None of it is as slick as NR with JRMC.

What I have been hoping for since I discovered JRMC is a way to get it communicating with my Squeezebox. I have MC going out to my PC (obviously), as well as my living room via TiVo, a spare bedroom via TiVo, and outdoors via wireless speaker & NR.

The Squeezebox is in my bedroom. I play music there every day and it always annoys me that it can't share play data, ratings, and smartlists with MC which I listen to everywhere else. (I know there are other devices that work with JRMC as a UPNP server, but I had already bought the Squeezebox before I found JRMC. Also I'm not sure if the other devices offer a sleep timer and alarm clock, which the Squeezebox has and I wouldn't want to give up in the bedroom.)

Anyway… if NR could become another controller option for Slimserver, it would be grand. If it could do it using JRMC's database it would be even better!

kurtlewis
July 31st, 2006, 12:33 AM
Sure Ben- that would definitely be pretty slick. Hopefully their dev docs will reveal if it is possible or not-

kurtlewis
July 31st, 2006, 12:40 AM
...... Also I'm not sure if the other devices offer a sleep timer and alarm clock, which the Squeezebox has and I wouldn't want to give up in the bedroom.

Now that is a novel idea. Ben, how tough would it be to add an alarm clock function to NR.. Start playlist or song on wake time? I suppose it would need to be a bit user-friendy for time set, choose song / playlist, etc.

I can envision the new Samsung UMPC running NR sitting by my bed... :)

emmee
July 31st, 2006, 10:51 AM
Hi emmee-sounds like I may have offended with my comments, not my intention just my experience / opinion from using the software, which btw I still use. Please share your experience and I'm interested to know what comparisons and hardware you have used to validate your tests? What sound card, amp and processor are you running?



Kurt,

I'm not offended, just surprised.

My system uses an Anthem AVM20 v2 processor for control. I designed and built a combination Sample Rate Converter / DAC that uses an Analog Devices AD1896 SRC and Burr Brown PCM1794 DAC. This SRC chip sounds like it may be the same one Lynx is using as it claims the same 142 dB dynamic range. I designed and built my power amps. My speakers are also my own creation, and use Seas magnesium cone drivers in a fully active three-way arrangement. You'd have to spend 20 to 30 k$ to buy comparable performance. (see pics here: http://home.comcast.net/~emmee/Spkr_Pics/Front_View_w_Grills.jpg http://home.comcast.net/~emmee/Spkr_Pics/Front_View_wo_Grills.jpg http://home.comcast.net/~emmee/Spkr_Pics/Top_View_wo_Grills.jpg) I use a Paradigm Servo 15 sub to cover the lowest octave.

My main experience with MC has been with the UPnP server. I have a Philips media player that I modified to improve the quality of its S/PDIF output. In direct comparison between the digital outputs of my Denon DVD-2910 and the Philips player I could not detect any difference in sound quality.

I've just got my media computer's S/PDIF output wired into my system. The connection is via a buffer I designed and built and is wired with Canare coax and connectors. I'm using an M-Audio AP2496 sound card and ASIO driver. I'll be spending more time with this in the next few days to see how it sounds.



What I have consistently seen (running v11.1) is up to 50% cpu during music playback and usually stays around 28-30%. Using taskmgr as well for checking.

Have not posted, and I'm certain that there are no installation problems or problems with our test HTPC's.



This level of CPU usage is not normal and raises a red flag. Since you're using quite expensive sound cards, I'm sure your PC is also plenty powerful, so there's no reason you should be seeing such high usage figures. Searching MC's Interact forum, I found that some users were reporting high CPU loads in beta versions of 11.1. Are you using the latest release of MC? I really suspect that there's something going on that could very well be affecting the integrity of your data steams.

Also, are you using ASIO to route music data to your sound cards? (If not, Windows does not pass audio data unaltered.) Have you disabled all the DSP processing in MC? Is MC's volume set to 100%? A good test for accuracy is to play a DTS or AC3 file and see if it's decoded properly by a surround processor. If it's not, you don't have a bit-perfect data path. I've tried this via my UPnP and S/PDIF paths and it works.

Hope I'm not sounding too condescending here, just trying to figure out something that doesn't make sense to me. If your software and hardware are bit-perfect then you've got most of the problems solved. What remains are hardware issues that may be causing excessive jitter in the digital interconnection. This can be problematic, especially in complex systems that may have ground loop issues. The Lynx cards you're using claim to have transformer coupled outputs, so you should be on the right path.

kurtlewis
July 31st, 2006, 11:47 AM
My main experience with MC has been with the UPnP server. I have a Philips media player that I modified to improve the quality of its S/PDIF output. In direct comparison between the digital outputs of my Denon DVD-2910 and the Philips player I could not detect any difference in sound quality.

I've just got my media computer's S/PDIF output wired into my system. The connection is via a buffer I designed and built and is wired with Canare coax and connectors. I'm using an M-Audio AP2496 sound card and ASIO driver. I'll be spending more time with this in the next few days to see how it sounds.

Hey emmee, nice job on the speakers- I would definitely be proud of those. I think I see why you do not notice a diff in sound quality between the PC and the Philips. It's the M-Audio card. I guarantee it is restricting your output quality and is on about the same quality level as the Philips' output. I've used practically every card on the market and only the Lynx cards offer that extremely high level of sound output transparency and openness. Also, if you have a good card you should never need to use a separate buffer!
One other card that is a notch or two up in quality from M-Audio is Digital Audio Lab's CardDeluxe. Very nice sounding card and even has an AES/EBU option. About $300-$400 online. Blows doors on the M-audio and will up-sample the audio output to 24/96.
Another important issue for us is clock accuracy. I have had repeated problems with M-Audio's spdif output locking up our test surround processors- We use quite a range, An Anthem AVM30, Lexicon MC1 v4, Theta Casanova MKII, Arcam AVP700 and AV9, and the 'bad boy' Theta Casablanca III with Extreme DACS and a Gen IV DAC. We use amps from Theta, and speakers from Martin Logan or Genesis Audio. Cables are all Synergistic Research Actives. On our test processors, only the Lynx cards and the DAL CardDeluxe have provided flawless operations. Usually the lockups occur when the PC switches source output through the sound card from PCM to non-audio, then back to PCM.
Canare cables are decent, however I would suggest moving to Synergistic's lower to mid-line Active series. http://www.synergisticresearch.com/alpha-st-as-a-ic.html You will see a bit of improvement in openness, but your largest bottlenecks will still be the AVM and the M-Audio card. I would also suggest the Arcam AVP700 or AVR350 as a next step up from the AVM20- AVP700 retails for $2100 (seen them on audiogon for $1700, AVR350 retails for $2500). This will definitely improve your sound over the AVM, particularly for surround-encoded movies. Arcam's quality is extremely impressive, and the price is a total value. Also has good RS232 control and I have working G4 files.

So I'm sure our requirements and my references to the lacking sound quality out of MC will only become readily apparent at the higher end of the audio gear spectrum. Some of our customers spend well over six figures on their systems, and subtle changes in sound quality are very noticeable here.




This level of CPU usage is not normal and raises a red flag. Since you're using quite expensive sound cards, I'm sure your PC is also plenty powerful, so there's no reason you should be seeing such high usage figures. Searching MC's Interact forum, I found that some users were reporting high CPU loads in beta versions of 11.1. Are you using the latest release of MC? I really suspect that there's something going on that could very well be affecting the integrity of your data steams.
Yep, using latest build- I may have to try another uninstall / reinstall as it's always possible in the Windows world that something may be messed up.


Also, are you using ASIO to route music data to your sound cards? (If not, Windows does not pass audio data unaltered.) Have you disabled all the DSP processing in MC? Is MC's volume set to 100%? Not using MC's ASIO. DSP, clocking is disabled, vol is set to 75% as 100% was causing some clipping.
As a matter of fact, I was explicitly instructed by Lynx engineers to NOT use MC's ASIO (they are very familiar with JRMC). Apparently they are very displeased with the quality of the ASIO implementation in MC. I tried it out and noticed no improvement over DirectSound.


Hope I'm not sounding too condescending here, just trying to figure out something that doesn't make sense to me. Nah, no worries man- you sound like a pretty knowlegeable guy (and about as crazy as me with audio gear / electronics :)). Appreciate your comments and suggestions.

emmee
July 31st, 2006, 12:38 PM
Hey emmee, nice job on the speakers- I would definitely be proud of those.

Thanks! It took me about 18 months from start to finish, so I am proud.



Also, if you have a good card you should never need to use a separate buffer!

What I didnít mention is that Iím using some rather long cable runs since my computer is in the office. I have thirty-some feet to my main audio system and about 70 feet to my outdoor system. The buffer was used to boost the signal level to make sure I didnít run into any problems with transients corrupting the data stream. These long runs mean that Ďaudiophileí cables are out of the question.



Another important issue for us is clock accuracy. I have had repeated problems with M-Audio's spdif output locking up our test surround processors- We use quite a range, An Anthem AVM30, Lexicon MC1 v4, Theta Casanova MKII, Arcam AVP700 and AV9, and the 'bad boy' Theta Casablanca III with Extreme DACS and a Gen IV DAC. We use amps from Theta, and speakers from Martin Logan or Genesis Audio. Cables are all Synergistic Research Actives. On our test processors, only the Lynx cards and the DAL CardDeluxe have provided flawless operations. Usually the lockups occur when the PC switches source output through the sound card from PCM to non-audio, then back to PCM.

This sounds more like a protocol or logic / driver problem than a clock accuracy issue to me. I hope itís the sound cards that are locking up and not the processors. If not, it doesnít say much about the robustness of the digital receivers.



Övol is set to 75% as 100% was causing some clipping. As a matter of fact, I was explicitly instructed by Lynx engineers to NOT use MC's ASIO (they are very familiar with JRMC). Apparently they are very displeased with the quality of the ASIO implementation in MC.

This sounds pretty fishy to me. Why canít the Lynx cards handle 100%? The digital output should only be formatting the data into S/PDIF and sending it out at the right rate. If thereís some processing going on then looks to me like their digital filters are running out of dynamic range Ė not good.

As for Lynxís complaint about ASIO I donít understand this either. AFAIK, MC just passes data to the ASIO driver, just like any other device. The ASIO driver is responsible for getting the audio data to the sound card. I donít think MC has anything to do with ASIO.



Nah, no worries man- you sound like a pretty knowlegeable guy (and about as crazy as me with audio gear / electronics ). Appreciate your comments and suggestions.

Iím not as crazy as Iíd like to be Ė thereís always something else thatís using up my cash.:-x

kurtlewis
July 31st, 2006, 03:23 PM
What I didnít mention is that Iím using some rather long cable runs since my computer is in the office. I have thirty-some feet to my main audio system and about 70 feet to my outdoor system. The buffer was used to boost the signal level to make sure I didnít run into any problems with transients corrupting the data stream. These long runs mean that Ďaudiophileí cables are out of the question. Step up to a Lynx card- they have enough juice for runs three times those lengths with SPDIF. SPDIF is a lower-bandwidth signal and will transmit fine, but you do need a good card- Remember, the Lynx cards are made for these types of scenarios in production studios. Dolby Labs uses Lynx cards exclusively for post-production and remastering work.



This sounds more like a protocol or logic / driver problem than a clock accuracy issue to me. I hope itís the sound cards that are locking up and not the processors. If not, it doesnít say much about the robustness of the digital receivers. It's partially the drivers, partially the logic with how the signal switching and routing is handled in the card, but it is also the clock signal as well. Theta and other high-end processors are extremely good and incredibly accurate- but, they have very narrow tolerances for jitter or clock timing deviation. Not forgiving, to put it bluntly- So I wouldn't look at this as a defect but rather as some sort of attempt to 'standardize' SPDIF- Since there is in fact, no set standard for SPDIF implementation and it varies widely from manufacturer to manufacturer. Card makers like Lynx recognize this and keep their cards, drivers and internal routing as accurate as possible to avoid these types of issues. Of course, this is why professional houses all use AES- Because it is standardized.



This sounds pretty fishy to me. Why canít the Lynx cards handle 100%? The digital output should only be formatting the data into S/PDIF and sending it out at the right rate. If thereís some processing going on then looks to me like their digital filters are running out of dynamic range Ė not good. I seriously doubt this is the case. MC is sending analog PCM to the card, and the card is converting to digital / sending in SPDIF. Setting proper gains for your analog sources is always important, and will vary from system to system. Yours may sound fine at 100%, but mine sounds fine at 80%. Additionally, I need to gain every source app so relative volume output is the same whenther you pop in a move through Zoomplayer, listen to MP3's in MC, or watch a news video in IE.


As for Lynxís complaint about ASIO I donít understand this either. AFAIK, MC just passes data to the ASIO driver, just like any other device. The ASIO driver is responsible for getting the audio data to the sound card. I donít think MC has anything to do with ASIO.
ASIO drivers are implemented by JRMC, and are their own versions. MC has everything to do with their own ASIO output, and every company that implements ASIO drivers does so differently. If you get a chance, give Lynx a call, go to tech support, and talk to Paul Erlandson. He is a super cool guy and can explain in greater detail what the particular differences (and problems) are with ASIO implementations. Tell him you are considering purchasng a Lynx card and that you have questions about running it with MC's ASIO. He is very familiar with JRMC and running Lynx cards in HTPC setups.

Ben S
July 31st, 2006, 09:37 PM
Now that is a novel idea. Ben, how tough would it be to add an alarm clock function to NR.. Start playlist or song on wake time? I suppose it would need to be a bit user-friendy for time set, choose song / playlist, etc.

I can envision the new Samsung UMPC running NR sitting by my bed... :)

I've actually been meaning to do this for myself for quite some time. I do have one of my PPC's next to the bed to turn our "sleep music" on, and have been meaning to tie more stuff to it. This should be pretty easy via Lua. You can get the current selected tree node (or use from GAC+ request) and have a button for "set alarm" or something. Lua can watch the time, and execute a request at a specific time, plus jump NetRemote to a page with a snooze button.

Should be a fun project for someone not currently involved trying to wrap up NetRemote 2! :)

dhill
August 1st, 2006, 02:44 AM
What I have consistently seen (running v11.1) is up to 50% cpu during music playback and usually stays around 28-30%. Using taskmgr as well for checking.

Have not posted, and I'm certain that there are no installation problems or problems with our test HTPC's.I thought I would chime in on this part of the discussion since I do not have such expensive equipment (Nor make my own, What a great job you did emmee!). I am running MC 11.1.190 on a Athlon 64 3200+ system with 1 GB and I see CPU usage run about 4 (jumps around highest about 8%) while playing back 320 bitrate mp3s and with WMP11 I see at least double that (jumps around more high of 48%). UNLESS I have a visualization running then the CPU usage depends on the viz used. For example the 3D visualization: Spectrum Analyzer ups the CPU usage to 65%.

PLEASE try setting the visualization to ĎCover Artí and see what the CPU usage is. As there is no sense comparing apples to oranges.

cheers,
-dhill

kurtlewis
August 1st, 2006, 03:46 AM
Thanks for your suggestion dhill, I will try a re-install of MC and see if it makes a diff.

BTW all- I installed SlimServer 6.5b1 (latest beta) this evening along with the Moose and SoftSqueeze client control apps. Everything works pretty well, install was easy and the sound quality is indeed quite good. Definitely does not have the bells and whistles of MC but still plenty of functionality, overall I found it very simple to use. I think the big piece missing here is a more feature-rich UI for the client with easier access to features normally buried under sub-menus, and something designed specifically for touchscreen / ppc control (NR would be fabulous).

FYI, if you go to install this please be sure to install Java V5 and JavaMP3 first- Or the system will not work and you will get no sound. The SoftSqueeze client is java based.

iq100
August 1st, 2006, 11:35 AM
IMHO, J River's MC fails several tests, including loading and stability. I also do NOT like the idea that they try to re-sell the product every 6 months or so to the same community. It would be better to have a fair price that included future bug fixes and changes. It is a VERY proprietary system under the covers. I do not know what their relationship is as far as collecting and selling your listening habits to others. But they certainly do NOT value open and free expression.
http://willhavebeen.org/forum/forums/thread-view.asp?tid=69&start=1

emmee
August 1st, 2006, 08:36 PM
Step up to a Lynx card- they have enough juice for runs three times those lengths with SPDIF. SPDIF is a lower-bandwidth signal and will transmit fine, but you do need a good card- Remember, the Lynx cards are made for these types of scenarios in production studios. Dolby Labs uses Lynx cards exclusively for post-production and remastering work.

It's partially the drivers, partially the logic with how the signal switching and routing is handled in the card, but it is also the clock signal as well. Theta and other high-end processors are extremely good and incredibly accurate- but, they have very narrow tolerances for jitter or clock timing deviation. Not forgiving, to put it bluntly- So I wouldn't look at this as a defect but rather as some sort of attempt to 'standardize' SPDIF- Since there is in fact, no set standard for SPDIF implementation and it varies widely from manufacturer to manufacturer. Card makers like Lynx recognize this and keep their cards, drivers and internal routing as accurate as possible to avoid these types of issues. Of course, this is why professional houses all use AES- Because it is standardized.

I seriously doubt this is the case. MC is sending analog PCM to the card, and the card is converting to digital / sending in SPDIF. Setting proper gains for your analog sources is always important, and will vary from system to system. Yours may sound fine at 100%, but mine sounds fine at 80%. Additionally, I need to gain every source app so relative volume output is the same whenther you pop in a move through Zoomplayer, listen to MP3's in MC, or watch a news video in IE.


ASIO drivers are implemented by JRMC, and are their own versions. MC has everything to do with their own ASIO output, and every company that implements ASIO drivers does so differently. If you get a chance, give Lynx a call, go to tech support, and talk to Paul Erlandson. He is a super cool guy and can explain in greater detail what the particular differences (and problems) are with ASIO implementations. Tell him you are considering purchasng a Lynx card and that you have questions about running it with MC's ASIO. He is very familiar with JRMC and running Lynx cards in HTPC setups.


Kurt,

Unfortunately, I have to say that I disagree with just about everything you said here. This will probably be my last post to this thread.

I think you're doing a great disservice to the community here by posting things that are technically inaccurate. I'll try to clarify some of the most glaring items:

1) "SPDIF is a lower-bandwidth signal"

For a given sample rate and word length, the bandwidth of S/PDIF and AES/EBU protocols are pretty much identical. The main differences are in signal amplitude, transmission line impedance and channel status block structure. See here for a good summary: http://www.cirrus.com/en/pubs/appNote/an22.pdf

2) "Since there is in fact, no set standard for SPDIF implementation"

I'm quoting the following from the Rane website, bold text is my doing: "In the consumer universe we find the acronym S/PDIF (also seen without the slash as SPDIF) created from Sony/Philips digital interface format. This was also made an international standard and issued as IEC 60958-3 (same number, different dash as the professional version), and it conforms with the EIAJ (Electronic Industry Association Japan) standard CP-1201 (renumbered CP-340)" that can be found here: http://www.rane.com/note149.html

Also the entire IEC satndard that also covers the pro fromat can be found here on the ANSI website: http://webstore.ansi.org/ansidocstore/product.asp?sku=IEC+60958%2D1+Ed%2E+2%2E0+en%3A200 4
A search on the base spec number will return all the parts of the spec.

3) "MC is sending analog PCM to the card, and the card is converting to digital / sending in SPDIF."

There is no such thing as "analog PCM". PCM is by definition digital. Any software that's used to play digital audio reads digital data from a file (or web stream) and sends it to a sound card where it's appropriately formatted and sent out the card's digital output. The data remain in the digital domain the whole way through.


4) "ASIO drivers are implemented by JRMC, and are their own versions."

Here's a couple of quotes from Matt from J River in response to a query on the subject:

"Media Center (like any app that uses ASIO) leverages the Steinberg ASIO SDK. This is chained in at the tail of our playback as an output plugin.

We needed to do some extra leg to provide thread safety because Steinberg didn't handle this in their design.

ASIO drivers are for output devices like a soundcard, which MC uses but does not implement."



"MC has excellent ASIO support. It passes signals in a bit-perfect manner, which is validated by Myron and Mike's reports of using DTS and DD. (these require a bit-perfect stream)"



One final word of friendly advice: Be careful what you say in front of your clients. Some day you may find yourself talking to a person that knows a lot about digital audio and if you repeat some of this stuff it could cost you some business.

Good luck!


P.S. I did spend some time today listening to my system and compared ASIO to Direct Sound via my lowly M-Audio card. There is definitely a difference. The depth of the presentation via Direct Sound is compressed and high frequencies, like cymbals, have a grating and less natural shimmer. Image localization also seems less solid and natural.

kurtlewis
August 2nd, 2006, 03:42 AM
I think you're doing a great disservice to the community here by posting things that are technically inaccurate. I'll try to clarify some of the most glaring items:

emmee- that was a very mean and uncalled for post, and while it is perfectly fine if you disagree with me (as that is what forums are for- sharing thoughts and opinions)- It is NOT ok to launch a direct attack at someone, especially when your ammo and small bits of knowledge are coming purely from 'other sources'. I honestly don't understand your hostility or condescending tone, but I really do not appreciate it in the least bit.

Anyhow we're way off from the original topic and this is the most I care to digress- I know that you have no knowledge of working in the field professionally with these implementations first-hand, so please do not take this course with me unless it is what you actually know from experience. I could whip out web links which point to the contrary on about all of your counters, but really- It's the same as college- The real world is different from what you read in school books or what your buddies tell you. -And of course I wouldn't expect MC to say anything negative about their product, nor should they. It's a good product. I was simply sharing a view from an engineer at Lynx who I'm sure knows more about this than most. Plus we're only talking about this in reference to using with very high-end audio gear where these sonic differences are very noticeable. Please feel free to give him a call (info in my previous post) and tell him he's full of it, I'm sure he will enjoy the laugh.

Here's a real lesson on professional wiring runs, based on fact and examples of differences in signal frequency- With very long AES runs the cable is usually electrically converted to SPDIF with an AES/SPDIF transformer (Canare makes these), then converted back at the end point. This helps preserve signal quality. You can cite your web-search papers all you want, but when you do this for real and truly understand electrical characteristics, you will know that the higher frequency (about 6mhz) of AES is more prone to attenuation over long distances vs. the lower frequency of SPDIF (3mhz). You may know the term 'frequency' by the term 'amplitude'.
Lesson two- The AES electrical standard is based on RS-422 and is very well known / established / adhered to by hardware manufacturers, because all they need to do is slap in standardized differential RS-422 chips for the signal transmitters and receivers. The SPDIF electrical characteristics are not based on any known standard and are similar in nature to some video signals. It is implemented by hardware manufacturers with varying hardware / specs and with varying quality results. This is what I mean by 'not standardized', because it is not.
The SPDIF protocol is standardized as you pointed out, but we're not talking about the data format nor did I debate that. AES and SPDIF are exactly the same data format with differences in subcode information. The key to good sound is in the hardware quality and electrical characteristics of the signal. The rest (data) are just bits, and bits are bits. To put this in laymans terms for you, perfect bits through a crummy electrical medium will result in lousy sounding perfect bits. If this weren't the case, then Lynx would be out of business charging over a grand for a sound card... the nerve!



P.S. I did spend some time today listening to my system and compared ASIO to Direct Sound via my lowly M-Audio card. There is definitely a difference. The depth of the presentation via Direct Sound is compressed and high frequencies, like cymbals, have a grating and less natural shimmer. Image localization also seems less solid and natural.

-I'm not surprised. M-Audio cards are low cost for a reason, and are great as an inexpensive upgrade from a Creative or on-board card. For the price the M-Audio Audiophile 192 is my 2nd choice in decent entry level cards, the first being the DAL CardDeluxe, which really sounds quite spectacular.
Save up and get a LynxTwo-B or at very least a CardDeluxe- Your nice speakers and your ears will be very happy, and it might even make you less of a grouch.

iq100
August 2nd, 2006, 12:49 PM
emmee- that was a very mean and uncalled for post, and while it is perfectly fine if you disagree with me (as that is what forums are for- sharing thoughts and opinions)-
...
it might even make you less of a grouch.

kurtlewis, unfortunately, you may have run into a Jim Hillegass sychophant. His company has a long and continuing effort in trying to squash any sharing of thoughts and opinions which criticize his company and its products.

Maybe before Jim Hillegass gets old and dies he will change his ways. You can read more about the record of this comany, that goes back to long threads critical of his ways on AVS Forums, here:

http://willhavebeen.org/forum/forums/thread-view.asp?tid=69&start=1

Sorry emmee, myron, if you are NOT an unthinking sychophant :). But any fair reading of what he has done over the years, which include forging avatars, and attempting to win debates, by deleting, and editing posts, without mention, is IMHO a worse failure than how ASIO is implemented. His record of trying to shut down other forums, or their posts which are critical of his company, is NOT right.

If you value true openness and fairness, there are many other companies to choose from, that do NOT try and re-sell there product to the same audience every six months, and would not sell your listening habits to other companies.

iq100
delete my ideas by posting some of your own.

kurtlewis
August 2nd, 2006, 01:25 PM
All- Let's please get back on-topic, and remember this is supposed to be fun!

emmee
August 2nd, 2006, 09:37 PM
It is NOT ok to launch a direct attack at someone, especially when your ammo and small bits of knowledge are coming purely from 'other sources'. ... I know that you have no knowledge of working in the field professionally with these implementations first-hand

I was simply taking issue with your inaccurate statements. I see you've chosen to disregard your own words above and turn this into a personal attack. OK, fine.

In the technical world, its common practice to provide references in order to show readers that the writer has investigated the prior art on a given topic and to reveal his sources of information. Iíve never seen a technical paper that presents a theory or viewpoint that didnít have references cited. Usually a larger number of references in an indication of a more knowledgeable writer and more credible communication.



...so please do not take this course with me unless it is what you actually know from experience.

All of my statements are based on both theoretical knowledge and experience and I stand behind each one. If you have a valid, technical explanation as to why my statements are not accurate, please let us all know.

I have two electrical engineering degrees and over 28 years of experience in electronics analysis, design and construction. Besides countless designs in my "day jobs" I've worked on many audio designs including digital amplifiers with Dr. John Vanderkooy from the University of Waterloo. I'm an inventor named on 7 US patents dealing with topics such as active noise control, electronic solenoid diagnostics, remote sensor interfaces and switching power supplies. I think this qualifies me to speak about fundamental electrical concepts such as amplitude and frequency.


You can cite your web-search papers all you want, but when you do this for real and truly understand electrical characteristics, you will know that the higher frequency (about 6mhz) of AES is more prone to attenuation over long distances vs. the lower frequency of SPDIF (3mhz). You may know the term 'frequency' by the term 'amplitude'.

Please point to all of us here where I stated that higher frequencies are not attenuated more than lower frequencies in a transmission line.

And while you're at it, please describe to us how a transformer changes the frequency of a signal passing through it. (HINT: there is no explanation since this is impossible.)

Just what Ďexperienceí lead you to the conclusion that a pair of impedance matching transformers can take an AES signal, divide itís frequency by a factor of two and then multiply it back to itís original frequency? What principle of physics is involved here? Please explain.


Impedance matching transformers like the Canare units you mention do three things:
1) Provide galvanic isolation between primary and secondary for the purpose of breaking (or preventing) ground loops, primarily at power-line frequencies. Parasitic and intentional capacitance between primary and secondary circuits prevent these units from providing isolation at high frequencies. Canare uses a 470 nF ceramic capacitor in their transformers. (Yes, I have investigated these devices before purchase, opened and examined them and use them in my system, so I know from experience )
2) Convert digital audio signals between balanced and unbalanced configurations. Despite what you stated about frequency multiplication, the main reason for making the conversion from a balanced to an unbalanced signal is that coaxial cable used for single ended signals is much less lossy than the shielded, twisted pair cable used for balanced signals. This allows for either less loss at a given cable length or for longer cable length for a given loss.
3) Change the amplitude of the signal. Because of the impedance transformation (this is a result of unequal number of turns between the sided of the transformer), the principle of conservation of energy dictates that the voltage must change to keep the output power equal to the input power (neglecting losses, of course). Since AES calls for a 110 Ohm impedance and S/PDIF for 75 Ohm the voltage output on the 75 Ohm side of the transformer will be lower than on the 110 Ohm side. Can you tell me how much lower it will be? How about the turns ratio of the transformer?



AES and SPDIF are exactly the same data format with differences in subcode information.

Earlier you stated that AES signals run at twice the frequency of S/PDIF. Here you say theyíre ďexactly the same data formatĒ. So which one is it, same or different frequency? If itís different, please explain how two signals with identical data formats can have different frequencies.



The AES electrical standard is based on RS-422 and is very well known / established / adhered to by hardware manufacturers, because all they need to do is slap in standardized differential RS-422 chips for the signal transmitters and receivers.

OK, so youíre saying that expensive sound cards with AES interfaces are better because they ďslap in standardized differential RS-422 chipsĒ. Hardly a convincing endorsement.



I'm not surprised. M-Audio cards are low cost for a reason, and are great as an inexpensive upgrade from a Creative or on-board card.

A few posts back you stated that you couldn't hear a difference between ASIO and Direct Sound, presumably on a "high end" system:


As a matter of fact, I was explicitly instructed by Lynx engineers to NOT use MC's ASIO (they are very familiar with JRMC). Apparently they are very displeased with the quality of the ASIO implementation in MC. I tried it out and noticed no improvement over DirectSound.

Now you're saying that you're not surprised I heard that ASIO made a positive difference on my M-Audio card. So that makes a "low cost" card more revealing of data path integrity than a "high cost" card. Interesting...

emmee
August 2nd, 2006, 09:39 PM
All- Let's please get back on-topic, and remember this is supposed to be fun!

Alright,

This I can agree about.....

kurtlewis
August 2nd, 2006, 10:43 PM
I was simply taking issue with your inaccurate statements. I see you've chosen to disregard your own words above and turn this into a personal attack. OK, fine.

As I stated in my last post this is not on-topic. Go continue your tyrade under a new thread. You can even name it "I know everything and you don't because I'm an uber-patent-owning-double-degree-kung-fu-ninja-electronics-master", or whatever, but just do it somewhere else because your statements are so dumb I can't even bring myself to answer them. Were those mail-order degrees?

emmee
August 2nd, 2006, 11:21 PM
As I stated in my last post this is not on-topic. Go continue your tyrade under a new thread. You can even name it "I know everything and you don't because I'm an uber-patent-owning-double-degree-kung-fu-ninja-electronics-master", or whatever, but just do it somewhere else because your statements are so dumb I can't even bring myself to answer them. Were those mail-order degrees?


Nice display of maturity, Kurt.

You've shown us your true colors.....

kurtlewis
August 2nd, 2006, 11:37 PM
Nice display of maturity, Kurt.

You've shown us your true colors..... -Not really, I'm just not taking your comments seriously anymore. If you continue to persist with the bashing and non-respect of the main topic, you will be smacked back.

Who is the "Us" that you keep referring to in your posts... Multiple-personality disorder, or is your ego so large that you feel you can speak on behalf of all the Promixis staff and members here?

iq100
August 3rd, 2006, 10:50 AM
kurtlewis & emmee,

Refreshing debate. :)
Glad to see your posts are NOT deleted here.
Maybe it is in part because the developer here is in favor of open software, which anyone is free to read, understand, and improve.
F*K you, F*K me, so what, just words. Its ok.
To the extent we value music and technology we will eventually get back to the best way to accomplish this.
JRiver does not publish its source software and that greatly limits technical scrutiny. Bit perfect, low latency, output should not be a shouting match.

Back, on topic, my interest is synchronization of multiple playlists. So anyone can join, and with authorization, modify playlist-n, and those choosing to listen to playlist-n will experience synchronized playback. My understanding is that softsqueeze for playback, installed on any suitable PC box can accomplish this. Apparently this does not use broadcast/multicast packets, because I have seen statements here about re-synchronization at the start of each track. Is that correct? I would like to see this done in a TCPIP broadcast or UDP manner. Is Fast Ethernet, 100Mbps sufficient to avoid stuttering, for say n-audio streams. What if there are m-video streams also using the Ethernet network? Any one have data on the n and m, and what does Gb networks do to the n and m?

Also, to the extent that all of this exists inside of Windows, itself NOT a real time OS, and NOT open source, those facts make running repeatable latency, jitter, or "quality" measurements difficult, on a real world computer. I once used a Windows based laptop to run a psychological experiment to measure real time interactions. Later, it was shown that even fairly well designed software that relies on Windows APIs to accurately report time at the msec level cannot be relied on. A chain is only as strong as the weakest link, and when these are so "proprietary" as to be hidden, objective measurement suffers.

delete my ideas by posting some of your own.

Ben S
August 3rd, 2006, 06:15 PM
Thank you for agreeing to disagree, guys. I read both sides with great interest, and respect you both. Thank you for contributing to the Promixis community, it honestly is great to see people so enthused about home theater and audio.

kurtlewis
August 3rd, 2006, 06:26 PM
Thanks Ben- I guess at times a bit 'over-enthused', it seems ;p

Emmee, can we bury the hatchet now? Looking back over our posts, we're both being silly.

emmee
August 4th, 2006, 10:55 AM
Emmee, can we bury the hatchet now?

I "bury the hatchet" means ending the debate then it's already been done. Immediately following my last post....

sabes
August 10th, 2006, 10:48 AM
this software looks like a godsend for dedicated slimdevices users. the remote for the squeezebox is pretty basic, and i've been looking for a device that would be a slick interface for the unit. lots of sb owners like this unit (http://www.nokiausa.com/770), but it doesn't work that well with a mac (which i use for my music) via a network storage device. here's a link to some of the blogging on this unit:
http://forums.slimdevices.com/showthread.php?t=17837
http://forums.slimdevices.com/showthread.php?t=19303&highlight=770
http://forums.slimdevices.com/showthread.php?t=24841&highlight=770

it would be fantastic if promixis partnered with sd to blow sonos out of the water!

kurtlewis
August 10th, 2006, 11:24 AM
Sabes- Nice tablet phone...and it even does wifi, wonder if NR would run on this-
(better pics) http://www.nokia.co.uk/nokia/0,1522,,00.html?orig=/770

*Edit* - n/m it runs a version of linux, so probably won't work (bummer). Specs / review: http://www.linuxdevices.com/articles/AT5858395674.html