Some startup help needed
|
06-03-2016, 20:48
Post: #11
|
|||
|
|||
RE: Some startup help needed
(06-03-2016 20:32)jacobacci Wrote: That worked, thanks a lot Simon I'm glad to hear this is working now. As I said in my earlier post, it isn't possible for a UPnP server or control point to determine the maximum sample rate that a UPnP renderer can handle because the UPnP protocol doesn't provide this information. |
|||
07-03-2016, 09:37
Post: #12
|
|||
|
|||
RE: Some startup help needed
I could see two ways around the issue of determining the maximum samplerate of the UPnP renderer:
- User manually tells MinimStreamer what the maximum samplerate of the renderer at IP address XXX.XXX.XXX.XXX is. This could be configured via MinimWatch. - Put a general field for maximum bandwith in MinimWatch. This would be a parameter that is valid for all renderers in the network, but it would be easily changeable Solution two would probably be sufficient for most users. |
|||
07-03-2016, 13:38
Post: #13
|
|||
|
|||
RE: Some startup help needed
(07-03-2016 09:37)jacobacci Wrote: I could see two ways around the issue of determining the maximum samplerate of the UPnP renderer: This wouldn't help because in UPnP the server is not able to change the sample rate based on which renderer is selected. The server sends the control point a selection of sample rates and the conbtrol point chooses one of these sample rates at the time that it selects a renderer to play the file. Your suggestion would therefore need to be implemented by the control point rather than the server. Quote:- Put a general field for maximum bandwith in MinimWatch. This would be a parameter that is valid for all renderers in the network, but it would be easily changeable The stream.transcode property already provides the capability to control this and I don't think it would be a good idea to add another property that modifies the stream.transcode settings. |
|||
07-03-2016, 15:16
Post: #14
|
|||
|
|||
RE: Some startup help needed
The quibble I have with the current solution is that all samplerates are resampled to the same target sample rate, also samplerates that would not have to be resampled.
The reason I would prefer a more differentiated transcoding / resampling behaviour for downsampling is that for a given processor power, resampling quality is best with integer resampling ratios and for a given quality, processor load is lowest for integer ratios. In my case, MinimStreamer runs on a Synology NAS, where processor power is a scarce resource. I wasn't thinking of introducing a new property that overrides stream.transcode. Regarding the stream.transcode property, am I correct in assuming that the parameters in the field are interpreted by MinimStreamer and then passed on to ffmpeg in a format ffmpeg understands? If that were the case, one could simply have a specific parameter that goes into the stream.transcode field that characterizes the max_samplerate of the transcoding table to be used and MinimStreamer would then use the appropriate transcoding table when giving transcoding parameters to ffmpeg. Someting like flac:wav24;96m flac:wav24;192m or flac:wav16;44m For DSF the problem does not exist, as the optimal output samplerates are multiples of 44.1, independent of whether the input file is DSD64, 128 or 256. Pls don't get me wrong, I am not trying to be difficult, just looking to get optimum quality for given resources. If what I propose is not doable, I am very happy with MinimStreamer being able to use SOX (big step up from ffmpeg). |
|||
08-03-2016, 12:02
Post: #15
|
|||
|
|||
RE: Some startup help needed
MinimStreamer is passing an exact sample rate to ffmpeg, not a maximum. There is no "table" in either MinimStreamer or ffmpeg.
A possible future enhancement would be to enable stream.transcode to take into account the input sample rate. For example, it might be possible to specify something like: flac;192:wav;96, flac;176:wav;88 to transcode from 192 kHz to 96 kHz and from 176.4 kHz to 88.2 kHz. I think this would enable you to do what you want. |
|||
08-03-2016, 12:50
Post: #16
|
|||
|
|||
RE: Some startup help needed
Simon,
That solution would give me exactly the flexibility I am looking for. I could basically build and maintain the transcoding "table" myself. Two things to maybe consider - the number of parameters that can be defined would need to be sufficiently high to cover all the samplerates above the renderer's max_sr - currently the highest commercially available input samplerates are 352.8 and 384 (for DXD files) - so for a renderer with 48kHz max_sr, 7 samplerate parameters would need to be specified (88.2, 96, 176.4, 192, 352.8, 384, DSF) Thanks a lot for considering my request. |
|||
10-09-2016, 11:19
Post: #17
|
|||
|
|||
RE: Some startup help needed
Hi
I am new on this forum but have used minimserver,streamer for a while and bumps on your thread Anyone knows how you specifie convert from dsf to wav with soxr filter precision 28 ? i am now using this and it is function good ,but want to test if this will work now it looks like this dsf:wav24;176 Hope you can help me QNAP TS451+,FFMPEG 3.1.3 Minimserver 0.8.4 update 88 Minimstreamer 0.5.25 |
|||
10-09-2016, 12:22
Post: #18
|
|||
|
|||
RE: Some startup help needed
See this post.
|
|||
10-09-2016, 20:55
Post: #19
|
|||
|
|||
RE: Some startup help needed
(10-09-2016 12:22)simoncn Wrote: See this post. Thank's i will try this |
|||
12-09-2016, 09:53
Post: #20
|
|||
|
|||
RE: Some startup help needed
(06-03-2016 16:35)simoncn Wrote: You are getting this error message because the ffmpeg provided by Synology doesn't support libsoxr. You need to download an ffmpeg static build for Linux with libsoxr support and specify the full path to this build in the stream.converter property. For a suitable build, see this page. I don't suppose there is a static build version for ARM under Synology somewhere? |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)