Jump to content

bluesman

Members
  • Content Count

    1980
  • Joined

  • Last visited

About bluesman

  • Rank
    Crusty Old Curmudgeon

Recent Profile Visitors

8719 profile views
  1. Your device setup audio settings may be controlling that. I don’t know how you set yours up, but options include fixed Roon output, volume control by endpoint device, by DSP etc. And there’s a setting for maximum volume that can be switched on or off and set to the desired level. None of my settings has been altered yet despite many updates and heavy use. JRiver media center has also been free of setting glitches in any version from 19 to 26 over years of heavy use. I use fixed / max output in Roon & JRiver and the volume controls in my DACs that have them (SMSL, iFi, M-Audio, Emotiva). One problem with DACs and other front end components is forgetting to turn the amp on last and off first. I drive a few basic amps directly and have been reminded of this the hard way. Fortunately, none of my front ends or DACs puts out much of a transient, but there are some that will take out a tweeter. It’s best to come up with the safest power-on and power-off routine for each system based on its architecture and settings and to follow it rigorously.
  2. I’m sure your thought is correct, Chris - without some kind of attenuation in the signal path, the only determinants of listening volume would be fixed by design. Sets of progressive density earplugs probably wouldn’t sell well, it’s hard to imagine a music library of FLAC verticals at graded modulation levels, and few of us have listening rooms sufficiently large for effective attenuation using movable seating and baffles. But the design and placement of attenuation in the signal path certainly affect SQ. Even the same methodology at the same point in the circuitry can be implemented well or poorly, e.g. simple progressive resistance in an analog stage can be accomplished with stepped high quality switching, components and assembly or a $0.50 pot. The divide between digital and analog volume control is much smaller than it used to be, but I think optimum use of one is still better than poor implementation of the other.
  3. Hi!! I'm thrilled that you're here and equally thrilled with the quality and content of your comments. This is a great opportunity for an open discussion of many of the issues affecting what you and so many other solution developers do. Let's explore how they affect you and the community of stakeholders drawn to your efforts, in the hope that we can be helpful to both you and the audiophiles who anxiously await the answers to their prayers First, as I said in my discussion above, "it's always fun to play with new programming platforms and to make something work better in some way. And I applaud anyone who tries a whole new approach to an old standard and truly improves on it". I've been there countless times since learning Fortran on my university's open source IBM 1620. I've been a software designer, creator and developer since 1965 and have remained current. For example, I "attended" Macromedia University and got certified as a ColdFusion developer about 20 years ago, and have learned and actively use the Cs, J, JS, VB, Ruby, etc. I've written a few dozen medium scale (100k to 250k lines of code) healthcare software systems in current use and a few larger works (500k+ lines) also actively running in major academic medical centers today. I personally installed and supported at least one each of these in 13 university hospitals around the country. I'm also a lifelong audiophile and professional musician with a pile o' Pis and other SBCs on which I've tried many novel things (some of which worked...) The big disconnect between you and the audiophile community in this case seems to me to be the unreasonable and unrealistic impressions given by third party reports of your work (e.g. the piece on Tom's by Ash Puckett a few days ago that started this thread). The web forum discussions that have sprung up (e.g. at opensourceforU and kitguru) also make it sound like it's ready for the kind of beta use that means "it works OK but there are bugs and glitches you can help us fix". These were clearly neither written by you nor based on information provided by you, although your own descriptive web page is a bit on the overly optimistic side. Your opening statement that "NymphCast is a software solution which turns your choice of Linux-capable hardware into an audio and video source for a television or powered speakers. It enables the streaming of audio and video over the network from a wide range of client devices, as well as the streaming of internet media to a NymphCast server, controlled by a client device" does give one (me!) the impression that it's sufficiently developed to be usable today by audiophiles with little or no specific computer knowledge or experience. Sadly, such distortions of what you're doing and where you are with it do you a disservice by creating unrealistic expectations like that "smooth end-user experience" you mention. Those who wrote that stuff about Nymphcast (and, therefore, those who read it) are either ignorant of or chose to ignore the simple fact that you "...only spent the equivalent of a month of full-time work on creating the basic ChromeCast experience from scratch". Knowing where you really are in this project puts it in an entirely new light, i.e. you're working your buns off to create a small, economical device that will source network files wirelessly to drive an endpoint, and (in the immortal words of the Carpenters...) you've only just begun. I think you'd do well to consider changing definitive statements like "Nymphcast is a software solution..." to "Nymphcast is being developed as a software solution..." etc. Although if you are successful it will someday do so, it does not now enable most Audiophile Style participants to stream audio and video over their networks. In point of fact, very few will get beyond looking at the setup executable and throwing in the towel. At least for the present, they are much better directed to the solutions I suggest above. I'd also suggest dropping the Buster-lite clone and spec'ing a standard Raspbian instance instead. I strongly doubt that swapping Dillo for Chromium is really necessary for smooth operation - and if it is, something else is wrong. I would also caution you to be careful in describing your work on a web page that looks to all the world like it's offering a workable system (bugs and all). I'm very happy that you have the opportunity to explain your project here, but those who learn of it from third party sources and go to it expecting something they can use today will be disappointed. This will reduce their interest in looking at it in the future, even though it might then do what they thought it would do now. Unless I missed it, there are other issues you might start addressing in your communications with the audiophile community, e.g. which file & output formats you plan to handle. When ready for prime time, will a Nymphcast server on a Pi do everything (audibly) that Roon Bridge does? How do you expect it to compare in sound quality to JRiver Media Center driving a CCA’s optical output, and why? Can you compare your projected performance to a widely used standard like MPD controlled by Cantata? What's the library management capability of what you're calling the player (and I'm assuming is the control point)? You'd also do well to respond quickly and accurately to every new thread about Nymphcast on any site. The best way to keep people interested is to stop the dissemination of drivel and let them know that you're honest and well equipped to bring your project to fruition. I hope everyone on AS will chime in and offer you constructive input, so you can both learn and make Nymphcast as good as it can be. We'd all love to be able to drop a download onto a card, fire up a Pi, and stream high quality music effortlessly to endpoints through our homes. We'd all like to see our brightest and best pave the way for the next run of innovators, and you appear to have what it takes to be a leader! Best regards - David
  4. As promised, I spent a bit of today's "social distancing time" exploring NymphCast. My executive summary is simple: It's a lot more work than it's worth, and I can't imagine why any audiophile would go to this much trouble to build a marginal solution to problems no one has. The system architecture is strange to say the least. Although the software you build on the Pi is called the server, the developer also calls it the receiver and it seems to be the renderer / player as its output is wired to the input of the device that will output your audio and video. You have to build a "player" on another device to use this. Per the developer, the player (which, I assume is the controller) "can be built on Linux/BSD/MacOS with a current GCC toolchain, or MSYS2 on Windows with MinGW toolchain". There's also apparently an Android APK. I got as far as executing the script that builds the "server" on the Pi and decided that I'd rather open a bottle of wine and sit in the living room with my wife. If you're an intrepid experimenter and just want to see how you do with it, don't bother downloading and setting up the "prebuilt image" from the developer. If your Pi isn't running the current Raspbian image or a very recent precursor, just download the latest stock NOOBS or Raspbian image yourself. The "prebuilt" image is just a September 2019 Debian Buster image with a few compromises that the developer must think make it "lighter", e.g. the embedded web browser is Dillo. For those who never toiled in the trenches of early IT, here's the human incarnation of Dillo: Once you waste time downloading, burning, and setting up the same OS image you already had on your Pi before (now without apps you actually use), you have another hour or two of work before you can even figure out if it will make music (and, if so, how good it is). All I can say is that if I needed a device to wirelessly retrieve networked audio files and play them through powered speakers or a TV / HT system, I'd use Kodi, Emby, Plex, VLC, or another such proven solution. Rooners can run Bridge on a Pi, and J River Media Center users can set up any DLNA software they like or run J River for ARM on the Pi to make it into a remote zone. I'd love to know what need the developer thinks she's satisfying with this, because I can't identify a single one. It's always fun to play with new programming platforms and to make something work better in some way. And I applaud anyone who tries a whole new approach to an old standard and truly improves on it. Maybe Nymphcast will be developed more fully into a package that keeps a Pi cooler, or speeds up the graphics, or improves SQ, or makes something else better. But for now, I just don't see that in the cards.
  5. It’s a crude CC substitute in that it’s wireless to the network and is controlled remotely by networked devices. If HDMI is the only digital out (or worse, the only out), it’s not going to be useful to many audiophiles. It looks like a long run for a short slide but I’ll put it through it’s paces.
  6. Yes indeed! It's cool, but the name is a bit misleading - it does not use the CCast protocol or the Cast SDK, so you can't 'cast to or from it. It's a media server that will retrieve source files stored on the network and output them to a renderer (which has to be connected directly because Wifi use is limited to your WLAN & it won't output BT audio). So far, all I know about output connections is that it uses HDMI - I downloaded it when I read about it, but I haven't had time to boot it up yet. On the face of it, I haven't read anything that differentiates it positively from the many other media servers available for RPi and other SBCs. I have to find out for myself (and for the rest of us) if it will output digital audio via USB and analog via the audio output. If it's limited to HDMI as the current scant documentation suggests, it's not a good match for powered monitors (which are pictured in the articles about it). So if it doesn't use USB, I assume it'll at least drive them with an analog signal - which is great for all of the mp3 fans on AS Nymphcast now says it's a beta release on Github (last time I looked, it was alpha). It only runs apps written in AngelScript for the Nymphcast platform. I don't think it's going to be a serious player (pun intended) in this game, but it's cool enough to deserve wringing out. I hope to be pleasantly surprised, but (as we need to learn to do today) I hope the best while planning for the worst.....
  7. The infestation has affected my playing much more than my listening. The club at which I'm the house band leader closed last Thursday, an hour before our weekly show was to start. Our Sunday blues brunch is over until at least May 22 (the scheduled reopening), and all the other clubs and restaurants at which I play one-offs are either closed or limited to take-out. I still listen at least a few hours a day while reading for pleasure, writing professionally, etc. But I'm practicing at least an hour more than usual every day to keep my chops up, which eats into my listening time. But we have another impact factor in our condo building - one couple have been quarantined in their apartment since returning home from abroad via Palm Beach. I'm a surgeon, so I know how to protect us and my wife's been excellent about not touching elevator buttons / door handles / etc with her bare hands, washing properly, and keeping her hands away from her face. We don't know these poeple and have never had any personal contact or communication with them. But it's more than a bit annoying that they didn't think about the rest of us and arrange for proper precautions here before returning. As far as I know, their tests were negative. But they've been selfish about the rest of the situation, so I'm assuming it was positive and acting accordingly. Thankfully, they're not on our floor.
  8. No worries, Brad. But this isn’t a matter of opinion - the physics of sound tell the story. The combined SPL of two sound sources of equal levels is an additional 3 dB, which (although clearly audible to listeners whose hearing sensitivity to the frequency range in question is adequate) is not a major difference. And I assure you that a tweeter crossing over at 2700 Hz is not putting out an SPL equal to that of the other drivers in that system - so its contribution to the speaker system’s output is less than 3 dB above the output of the other drivers. Even if totally nonfunctional, it would simply not cause a gross level discrepancy in comparison with the functional side.
  9. You might want to read my post above discussing this. Here’s the relevant quote so you won’t have to search for it: ”I don’t know where those terminals are in the crossover chain, i.e. whether there’s any filtration between them and the drivers or if they’re direct (which I doubt). You’ll need to find out from Revel, because it will affect the information this test will give you. If those terminals are inputs to the crossover, any imbalance could still be caused by a driver or a component in the crossover.” So as I said above, start with the wires and go to the driver itself if the problem is tweeter-related. I think it’s probably not, based on the description. A truly gross loudness discrepancy is unlikely if it’s the tweeter, which starts getting its drive at 2700 Hz in this system. This is especially true for a listener with what he describes as a severe high frequency hearing loss in both ears, unless he has a bizarre cochlear disorder with severe recruitment (which is also very unlikely). I think he’s much more likely to find the problem driving only the midrange down and will never have to test the HF circuitry or driver. I could be wrong, but the only data we have suggest that I’m not.
  10. It’s a lot easier to move wires between terminals than to swap tweeters, especially if you do it at the amplifier.
  11. You’re welcome - but to be honest, I suspect it’s not a tweeter and new speakers may be the best choice. Having said that, it’s always worth a thorough evaluation first. Measure very close to each driver - you won’t learn much from the ends of the couch. Hold the microphone right in front of the cone. A fixed measured distance is best, and a tripod or other stable support to hold it at the same angle makes the measurement even more repeatable. I still listen to the Rogers LS3/5a monitors I bought new in 1976, and my son uses my KLH 19s (circa 1969) in his home theater system. Age is just one factor for both speakers and for their owners
  12. I don’t think you know exactly what’s wrong yet - you’re trying to treat an unknown disease on the basis of guesswork, but you need facts to make the diagnosis. The fact that tweeters “often fail” in that model does not mean that yours did. You describe the imbalance as “severe” but say you can’t hear anything over 10k. Your tweeters start putting out at close to 3k, as I recall, and that’s where timbre, brilliance, “air” etc start to be defined but none of the fundamentals and major harmonics are that high. It’s a bit hard to believe that you can easily hear a gross imbalance in SPL from lack of output above 3k, especially if you truly have no functional hearing sensitivity above 10k. It’s a truly rare audiogram that breaks sharply at a specific frequency and even rarer if it’s bilaterally symmetric - so you almost certainly have a progressive loss of threshold sensitivity that starts at or below 1k. All you know for sure (assuming that it’s constantly on the same side despite swapping input or output channels/cables) is that there’s a problem in one of your speakers. There are several things you can do to get a more accurate diagnosis. A simple, cheap SPL meter is very useful, but if the imbalance is truly big, just download a free SPL “meter” for your smartphone You can use recorded music as a test source, but you might want to use an online sine wave generator to ensure consistency of input levels and signal between channels. You can use the audio out jack on your phone or computer - SQ is irrelevant here. Obviously an external DAC is also fine to use. I’m pretty sure your speakers are designed for biamping. Remove the jumpers and connect your amplifier’s outputs to the bass input terminals ONLY. Listen to and measure the SPL from each channel from a close, fixed distance on the axis of each driven speaker. Move your speaker leads to the high frequency terminals and do it all again. If using a tone generator, start at 1k and go up from there. I don’t know where those terminals are in the crossover chain, i.e. whether there’s any filtration between them and the drivers or if they’re direct (which I doubt). You’ll need to find out from Revel, because it will affect the information this test will give you. If those terminals are inputs to the crossover, any imbalance could still be caused by a driver or a component in the crossover. If the imbalance is audible only through the bass terminals, the problem is almost certainly not your tweeter. If it becomes audible at some point while sweeping the frequency upward using a tone generator into the full frequency inputs (with jumpers in place), you’ll know where it starts and that should narrow the search. Just for completeness, you might also want to check the jumpers themselves and the terminals to which they connect. And if it really is a tweeter, you can simply remove the jumpers and wire up to a pair of external add-on tweeters. There used to be many on the market. You could even use a good, small, inexpensive passive “monitor” as your new tweeter - there are many excellent ones for less than $100/pair. If your HF hearing is that compromised, this should be fine - just sit them on top of the Revels. To the inevitable critics about to post how terrible this solution is, I don’t think the phase and sensitivity differences will matter much to someone with poor high frequency hearing - especially when the stated alternative is to use boundary effect as a fix and listen to them as they are now. Good luck!
  13. Hi & welcome! I'm the author of that article, but I'm sorry to say that there's nothing at all in it about Gentoo Linux, GentooPlayer, or Botic. The next "chapter" in this series (completed and soon to be published) focuses on ARM-based operating systems for audiophiles, but it too lacks info on Gentoo, GentooPlayer and Botic. The main reasons that I didn't evaluate and include this combo are Gentoo Linux is not popular with audiophiles who want to boot and forget their OS - it takes a bit more work than many this series is about finding value in computer audio equipment, and the Twisted Pear kits I've seen are a) costly & b) kits Reviews of their stuff over the last several years suggest very fine sound quality that doesn't appeal to everyone Some of their kits are well over $USD500, for which you can get some very fine DACs with great sound & specs in housings that are much more attractive than most homemade or generic commercial cases. Only if SQ is better than that from attractive, assembled devices at or above their cost would they represent great value both Gentoo and Botic appear to be more than a little finicky on BBB per posts & disclaimers like these on bbb.ieero.com: "Using BBB without external clocks the audio files with 44.1kHz, 88.2kHz or 176.4kHz sampling frequencies will be resampled to multiples of 48kHz. This might/will introduce hearable artifacts." "I do not recommend to use direct I2S or I2C connection between DAC and BBB. Such connection does not provide necessary protection to BBB. One should use something like cape with isolators. Otherwise be prepared that your BBB might be destroyed." There are many great and simple Linux distros for the BBB with some fine audiophile players. MPD on Debian sounds quite fine into a good USB DAC to most audiophiles who either don't want to spend a lot more or don't think there's a commensurate improvement in SQ at much higher cost. I agree with them. Roon Bridge works fine on a BBB running Debian - I'm listening to exactly that right now while preparing this post. The 'bone doesn't have sufficient USB power for many DACs, so I use a powered hub or a separate PS. The Twisted Pear Buffalo-IIIsePro-28 may be outstanding, but it costs more than many others of similar spec. I plan to include it in a value-based DAC review and comparison to follow the article I'm preparing now on getting the most audio utility out of SBCs like a Pi, BBB, etc as soon as I save up the money to buy a few more pieces for review. I've bought current units from SMSL, iFi, M-Audio and a few others in the well-under-$500 category. But the Twisted Pear pieces are at the top of or slightly above that category. I'm trying to find a friend with one I can borrow rather than buy, since the hassles of reselling after testing are becoming burdensome. If I succeed (or my wife is feeling generous), I'll include one. GentooPlayer may be great and Botic Linux may be a wonderful choice for the 'bone - I don't know because I haven't tried it. So I just downloaded the current image and will see how well it performs for me.
  14. Great piece! FWIW, Stax cushions have always seemed a bit thinner & more fragile in feel than most others. They actually glued themselves together on my SRX Mk 3s after being left unused for a few months when we built our house & moved. Thanks for the info & its articulate presentation!
×
×
  • Create New...