Jump to content

chip

  • Posts

    30
  • Joined

  • Last visited

  • Country

    country-ZZ

Retained

  • Member Title
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I understand that some things are out of your control. Just hoping. I was just joking around about sales in general. I certainly did not mean any disrespect for Adrian. I had a very good experience with him when I bought my SSR.
  2. typical sales guy!! I deal with them all the time. I project manage for an industrial automation company and sometimes I really am astounded by what sales guys tell customers and potential customers. Good luck with this. Let me know if anything develops.
  3. I am interested. Expensive is relative, what do you have in mind? Can it be done remotely? I am in Europe so doing something here could save transport cost.
  4. btw, Adrian' comments in January 2017 I have referred to are: "Saying all this the developers of the SSR board (which we were Apprx 15% off) are working on a replacement board. We definitely are keeping an eye on them. "
  5. I can perfectly understand the economics of what you are saying. I just find it a bit disappointing. I have always looked at niche companies, like Sonore, to provide niche products but if that is not possible for survival then that is the way it is, like it or not. You must survive as a company. I would certainly be one of the few (here ot there) that would be interested in any new I2S products you may develop based on my experience with my SSR. I had hoped for the upgrade that Adrian talked about last year. Do you consider that a possibility or is this also off the development schedule?
  6. btw: I did not give up on it. I am still using my Signature Series Rendu I2S interface to my PS Audio Direct Stream DAC.
  7. It sounds like the answer to my questions is YES. After proclaiming this as the best interface Sonore, it was included in their now discontinued Signature product, has now decided that due to commercial reasons (or maybe being too early to the party) they do not have any current plans to offer products with an I2S interface to high end DACs. I am not trying to be rude but I am just trying to get some clarity.
  8. I am just wondering so I thought I would ask. Has Sonore given up on the I2S interface? It was in their top of the line equipment not long ago and now I do not see or hear anything about it in the products or forums.
  9. Since it has been just over 4 months do I need to assume that you will not be looking into correcting this problem with the SSR?
  10. Hi, Please let me know what you decide. I am very interested in having this capability to make my systems work together. Thank you, Chip
  11. Hello, OK, I understand why the problem with DSD128 to dopwav does not work. Now I am back to the original reason for my post - MIME types. Is it possible to update the firmware in the SSR to advertise the audio/x- MIME types so MinmServer and BubbleUPnP can recognize the stream type to send? So it will advertise: audio/dsd audio/dsf audio/dff and audio/x-dsd audio/x-dsf audio/x-dff like it already does for audio/flac and audio/x-flac? I think this would make the SSR more compatible with different systems. Thank you, Chip
  12. Hello, I just went over to the PS Audio website and it says the DirectStream DAC will play: Sample Rates I2S,S/PDIF, and USB -- 44.1kHz to 352.8kHz 16bit, 24bit, DSD 64, DSD 128 TOSLINK – 44.1kHz to 96kHz 16bit, 24bit XLR (AES/EBU) -- 44.1kHz to 192kHz 16bit, 24bit, DSD 64 I am using the I2S interface from my SSR to the DS DAC so my statement in the previous post: The PS Audio does not playback 352.8 kHz files is wrong! Now I am more confused about why the DSD128 file did not playback correctly. I then tried the file again and had the same results. Sorry about my confusion, Chip
  13. Hi, Music Library MinimServer 0.8.4 update 88 MinimStreamer 0.5.2 stream.converter ffmpeg314 Bubble UPnP Server Version 0.9-update21 Control Point Samsung Galaxy Tab S2 tablet BubbleUPnP version 2.8.3.1 Renderer Sonore Signature Rendu shown as Audio Render-143 (OpenHome) DAC PS Audio DirectStream DAC NativeDSD downloads used for testing Sarah Vaughn - Live at Rosy's DSD64 - 09 A-Tisket, A-Tasket.dsf DSD128 - 09 A-Tisket, A-Tasket.dsf MinimStreamer stream.transcode values and results from 2016-12-08 testing requested by Sonore MinmStreamer stream.transcode value <empty, no values> and restart server DSD64 file PS Audio displays - Input: DSD Rate: DSD64 1 bit BubbleUPnP displays - DSF | 2822.4 kHz | 1 bit DSD128 file - small spike before playback PS Audio displays - Input: DSD Rate: DSD128 1 bit BubbleUPnP displays - DSF | 5644.8 kHz | 1 bit This plays back as expected with only a small spike when changing from DSD64 to DSD128. Clear BubbleUPnP playlist MinmStreamer stream.transcode value "dsf:dopwav" and restart server DSD64 file - small spike before playback, switching from DSD128 to DSD64 PS Audio displays - Input: DOP Rate: DSD64 1 bit BubbleUPnP displays - WAV | 176.4 kHz | 24 bits DSD128 file - small spike before playback, switching from DSD64 to DSD128 PS Audio displays - Input: DOP Rate: DSD64 1 bit BubbleUPnP displays - WAV | 352.8 kHz | 24 bits Playback of this track sounds like it is at half speed The PS Audio does not playback 352.8 kHz files The time slider on BubbleUPnP moves to 100% but timer keeps counting until 3:39 but the track is only 1:49 long The DSD64 file plays back as expected but the DSD128 file does not playback properly Clear BubbleUPnP playlist MinmStreamer stream.transcode value "dsf:wav24;176" and restart server DSD64 file PS Audio displays - Input: PCM Rate: 176.4k 24 Bits BubbleUPnP displays - WAV | 176.4 kHz | 24 bits DSD128 file PS Audio displays - Input: PCM Rate: 176.4k 24 Bits BubbleUPnP displays - WAV | 176.4 kHz | 24 bits Both playback as expected without spikes Is this the test you wanted me to perform? Do my results help you identify the issue? Please advise, Chip
  14. I received some additional information from Simon this morning that could be interesting, it certainly is to me. ------------- start of update from Simon ------------- There is a list of registered MIME types on this page. For streams that match one of these types, the registered type should be used. Many of the audio streams in common use don't match any registered type. In this case, the convention has been that a type starting with 'x-' should be used to indicate that the type is not one of the official ones. There is no list of the 'x-' types and these become "standard" by accepted usage rather than by inclusion in a formal list. This approach was recommended by the MIME type specification for many years (see section 2.1 of this document) but the recommendation has now been changed (see this document), so I should not have described Sonore's choice as "not correct" in my previous post. Unfortunately, the water has become quite muddy over the years with different type names used by different products for the same stream, including an apparently random mixture of types with and without the 'x-' prefix. This has caused compatibility problems between streamers and renderers and is a generally unsatisfactory situation. Each stream advertised by the server has a single MIME type. However, the renderer can advertise compatibility with multiple MIME types for the same stream type. Sonore is already doing this for some streams (e.g., audio/flac and audio/x-flac). The fix for Sonore is therefore not to change the existing DSD types such as audio/dsf but to add new types such as audio/x-dsf alongside existing types such as audio/dsf. ------------- end of update from Simon -------------- This both clarifies the issue for me and helps me understand the confusion many of us have about a standard that is not really a standard. At this time it seems like the most foolproof way to go forward is to add both variants of the audio MIME type to insure compatibility. I hope we can find a solution that allows everything to work together. Thanks for all your attention and ideas, please let me know the outcome of your discussions. Thanks, Chip PS: I will try the test you identified in your past when I get home this evening.
  15. Hi, I have been debugging this problem with the developer of MinimServer this evening and we have come to the following conclusion. The SSR is responding with the wrong MIME types for DSD audio. We issued a "GetProtocolInfo" command to the SSR and it responded with the following capabilities. http-get:*:audio/flac:*,http-get:*:audio/x-flac:*,http-get:*:audio/wav:*,http-get:*:audio/x-wav:*,http-get:*:audio/mpeg3:*,http-get:*:audio/mp3:*,http-get:*:audio/x-aiff:*,http-get:*:audio/aiff:*,http-get:*:audio/aac:*,http-get:*:audio/mp4:*,http-get:*:audio/m4a:*,http-get:*:audio/dsd,http-get:*:audio/dsf,http-get:*:audio/dff The last three protocols relate to DSD: http-get:*:audio/dsd http-get:*:audio/dsf http-get:*:audio/dff But these are not officially supported MIME Type responses for DSD files. The SSR should respond with: http-get:*:audio/x-dsd http-get:*:audio/x-dsf http-get:*:audio/x-dff Does this make sense to you? Do you think it is possible to get a firmware update for the board to correct this? Chip
×
×
  • Create New...