@hnl_dk
After a close look at my current SDK, I think I understand why the coreutils are mixed in with gcc and binutils. If you install Sebastion's beta tool chain as GCC_5.x.x in the SDK, you can change the GCC: assignment to SDK:GCC_5.x.x to compile with the newer toolchain without disturbing the files in SDK:local/C. The coreutils in GCC_5.x.x will be found first when compiling with the newer GCC. Changing the GCC: assignment back to the original GCC directory will then allow you to compile with the original stable toolchain. Smarter people probably understood that before I did.

I still think your coreutils archive should contain a readme file explaning that the original SDK coreutils will be deleted. In fact, it wouldn't hurt to add some lines to the installer script informing the user that the original files will be deleted and offer a choice as to whether to continue with the install or not.

@broadblues
Quote:
I understand what Sebastion is doing but for someone who hasn't been following the adtools changes, things could be a little confusing. For example, if you search for adtools at Github, you will find sba1/addtools but not Jen's adtools that has repositories for multiple developer tools. On the other hand, if you search for clib2 you will find sba1/clib2 and adtools/clib2. Then there are the repositories for a lot of the developer tools that are at Sourceforge but have actually been moved to Jen's adtools at Github.

@hnl_dk
Quote:
In case you aren't aware, there are 3 adtools repositories.

There is https://sourceforge.net/projects/adtools which contains the sources for the current 'stable' toolchain for OS4 (used in the current SDK).

There is https://github.com/sba1/adtools where Sebastion has set up a system for merging OS4 specific changes with more recent GCC toolchains. I think you might need Linux to obtain code from there. The last time I tried to get code from there, OS4 Python couldn't handle the scripts that Sebastion used.

There is https://github.com//adtools which Jens Maus has set up and contains other development tools. I don't know why everything has gotten split up between several repositories but it has.

@hnl_dk
Quote:
Agreed but I think someone uploaded that adtools compile because people wanted to compile a program that required GCC 5.x or better. I think it's an adtools binary snapshot and not an official release. I recently D/L a binary snapshot of gcc 5.4.0 from https://dl.bintray.com/sba1/adtools-native and it also has the coreutils mixed in with bintutils & gcc.

I just thought it was worth mentioning because if people are installing newer adtools that way, your coreutils in SDK:local/C might not get used.

@hnl_dk
Sorry. My bad. I D/L the wrong diffutils from OS4Depot.

@AmigaBlitter
We already have diffutils 2.8.7 in the OS4 SDK. Why would we want to replace them with older diffutils 2.8.1 versions??

@Thematic
Quote:
In my SDK:S/gcc-startup GCC: is assigned to SDK:gcc, so it is really the same place. Unless you've changed your SDK startup files, GCC:bin is SDK:gcc/bin.

@Raziel
Saving some disk space back in the day when Amigas had 20MB hard disks might have been useful but it's an unnecessary gimmick is this age of multi-terabyte hard drives. However, if it works for you that's fine. I just think that the unusual method for installing coreutils should be explained in a readme file in the root directory of the archive.

It also might be worth noting that the adtools.lha archive at OS4Depot and more recent version at Github place the coreutils in SDK:gcc/bin along with the binutils so the coreutils in SDK:local/C will never get used. If you are still using the original SDK (containing gcc 4.2.4) then there's no problem; Henning's coreutils will be used.

@Spectre660
It looks like switching to an SB Live card did the trick. TuneNet radio played for 2 hours last night with heavy browser use and 3 hours this morning with moderate browser use. No TuneNet freezes now. With the CMI8738 card TuneNet never made it to 30 minutes before freezing. Thanks for th help.

@Spectre660
I read that thread which seemed to indicate that it's revision 1 of the sound card that has problems. Since Ranger shows my card is revision 0x10 (i.e. hex for 16), I thought the problem didn't apply to my card.

I've had the best sound card results with my old SB Live card in a Sam440 and X1000, so I'll give that a try tommorrow and post the results here after some tests.

EDIT: I replaced the CMI8738 card with my SB Live card and it's working. However, it will take until sometime tommorrow to see if TuneNet works normally with the SB Live.

@amigakit
My system from AmigaOnTheLake might have a different combination of cards than the systems you tested. I have a PCIe network card, a CMI8738 based PCI sound card and a sii3512ide based SATA card. I also have a CMI8738 based PCIe sound card and an SB Live card that I can try. Is there any problem with which PCIe slot a sound card can go into?? There is already a PCIe network card in the bottom PCIe slot.

P.S. I played local MP3 songs for 3 hours without activating my network and TuneNet had no problems. I started TuneNet with the network active and started it playing before starting this post. TuneNet froze while I'm writing this post.

@tonyw
If you check out the image at the link in his original post you'll see that the files are all being deleted on a single command line. Presumably, the line is longer than AmigaDOS, the console or rm can handle.

I've been testing programs on my X5000 and have a problem with TuneNet freezing while playing Internet radio. It can freeze after a few minutes but never plays longer than 30 minutes. Once it freezes, no other programs can play any sound. Only a reboot clears things up. It's pretty much unusable unless I wan't to reboot every 20 minutes.

@AmigaBlitter
Quote:
Something doesn't seem right about the binary archive (coreutils-bin.lha). There are no individual coreutils commands in the archive. The installer deletes the current coreutils in SDK:local/C and replaces them with a single file named "coreutils".

@mritter0
Quote:
Strange, it didn't work on OS.14FE on my X1000. I think I'll try the version from OS4Depot again with OS4.1FEupdate1.

@mritter0
I've seen FTPMount mentioned in this topic a number of times. The FTPMount from OS4Depot stopped working for me as of OS4.1FE. I fixed the included sources for my own use with Dopus4 but I'm wondering where you and others are getting a working version for use with OS4.1FE. Have you tested FTPMount with Workbench Explorer?

@broadblues
Quote:

Actually, I think CDDA music files are being played by the aiff.datatype and it's probably that datatype that needs to be updated by A-EON or the OS4 devs in order to have it play 16 bit sound and report 16 bit attributes.

I'm suggesting that aiff.datatype be updated. If Kevin has the skills to create the mpega.datatype and an updated WAV datatype, I'm assuming he could create an updated aiff.datatype for the next Enhancer release

@amigakit

I just received your email and replied. The new (fixed) datatypes fix the problem with external sound files in my USBSound porgram. The 8svx and WAV datatypes now return fairly accurate time, samplesize & sample length. The mpega datatype is now returning the same attributes accurately for MP3 files but that may depend on the accuracy of the MP3 file header.

The time for CDDA files seems accurate but both the new Enhancer sound. datatype AND the OS4.1FEu1 sound.datatype show exactly half the samplesize and samplerate with questionable sample length. That may be because (as the autodoc states) CDDA sounds are converted to 8 bit samples at half the samplerate if AHI is unavailable. That may have likely been the case for OS3 but AHI will always be used in OS4 so it wouldn't hurt to change an OS4 sound.datatype to return the correct attributes (16 bit at 44,100 sample rate (freq)).

I'm happy with the fixed datypes and other programmers & users will probably be happy too.

Thanks for the quick turnaround on my bug report.

@broadblues
I PM'd Amigakit but didn't get a binary. However, you know what the problems are and can test an updated sound.datatype before it's release.

@ChrisH

Based on experience, here is my explanatiton for AHI settings:

If you select a sound card or built-in audio like hdaudio for X1000 in the AHI "Music Unit" lister, then applications that use the low-level AHI API will have exclusive access and other applications will not play at the same time. Some things like notifications won't work.

In AHI, if you set one of the "Unit 0" settings in the "Music Unit" lister and set a sound card or built-in audio setting in the "Unit 0" lister then any applications that use the low-level API will have their sound play rerouted to "Unit 0" and won't have exclusive access to AHI and block other applications (like notifications) from playing.

If you set one of the "Unit 0" settings in the AHI "Music Unit" lister, then the TuneNet settings won't matter. However, it's probably better to use "AHI Audio 0" (AHI unit 0) in TuneNet as broadblues suggested.

Supposedly, the low-level access to AHI resulted in better sound quality on a classic (OS3) Amiga but I've never been able to tell any difference on my OS4 NG computer.

By the way, it's the SYS:Devs/AHI/device.audio file that makes "Unit 0" show up in the AHI "Music Unit" lister. Without that file, there is no way to reroute low-level AHI access to Unit 0.